P2: Write the incident response runbook

Why

#1’s definition of done wants a deployment runbook covering TLS, firewall, backups, audit shipping, and incident response. docs/operations.md covers the first four. Nothing tells an operator what to do after a compromise, which is the moment when guessing is most expensive: the instance is one process holding the accounts, the keys, the repositories, and the audit log, so there are few right moves and many wrong ones.

Scope

A section in docs/operations.md, linked from its own index and from docs/README.md:

• What counts as a security incident here, and who is told.
• Preserve first: stop the service, copy the data directory and the audit log before changing anything, and do not rewrite the vole branch — that renumbers issues and rewrites the history the audit log refers to.
• Account or key compromise: retire the account, revoke sessions, replace the SSH host key, and what that breaks for existing clones.
• Runner compromise: what a job container could reach (the network only when the runner was started with a bridge, the repository’s identity, the job’s credentials), and what to treat as forged afterwards.
• Administrative misuse: which records survive, what vole admin can and cannot undo, and where the audit log is the evidence.
• Data loss and a full disk: the shortest path back, pointing at the restore drill rather than repeating it.
• Certificate and ACME failures, and the difference between an expired certificate and an expired account.
• Post-incident: what to write down and where, and the release note to attach when a public fix lands.

Acceptance

• The section exists, is linked from docs/operations.md’s index and from docs/README.md, and names concrete commands rather than describing them.
• Every scenario above has an action, and nothing in the page is a secret.
• #1’s runbook line can be ticked with a link.

Part of #14.