v0.8 — Audit devices

The only thing in Vault that answers "who read that secret."

scripts/bootstrap-audit.sh enables audit devices on the cluster. It
enables two by default, and that is the part worth reading twice.

The tradeoff, stated plainly

Vault refuses to service requests when it cannot write to any enabled
audit device. That is the correct behaviour — an unlogged request to a
secrets manager is worse than a failed one — but it means a single audit
device turns a full disk into a total outage.

Two devices is the mitigation. It is also why --force will not let you
disable the last remaining one.

Entries are HMAC'd rather than recorded in clear, which is what makes the
logs safe to ship somewhere central.

Tested

CI covers the failure modes, not just the happy path:

• that two devices are enabled by default
• that --force cannot disable the only remaining device
• that an enable which succeeds without actually enabling anything is
  treated as a failure, not a pass

What this does not do

Nothing forwards the logs anywhere. Both devices in the local profile
write to the same filesystem — which proves entries reach both, and
proves nothing about surviving a full disk. A second device on an
independent failure domain is what a real deployment needs, and it is
now the third of three blockers on the road to v1.0.

See docs/audit.md.

---

This is the first cut release. Tags v0.1 through v0.7 were applied
retroactively at the commit where each version's scope was complete —
a fair reading of the history, but not the same as having released at
the time.