retention: administer versioned policies and attributed holds

[TusanHomichi]

Outcome

Deliver the first reviewable vertical stage of #64: operators can configure versioned retention policies and administer attributed holds through the web. Explicit manage_retention grants are never included in a role bundle; existing manage_users authority can grant or revoke this separate capability with a recorded reason.

Scope and decisions

• Immutable policy versions per supported record class (daily report, weekly summary, phase evaluation, disposition event). Each names its authority, trigger, retention period, action, and reason. Replacing the current policy requires its expected version; competing replacements refuse stale input.
• Typed triggers: finalization or enrollment closure for evaluations; disposition time for independently retained disposition events. Durations are explicit elapsed days. Actions are retain or destroy; authoring a policy never runs destruction. No default agency policy.
• Holds scope the installation, an enrollment, or a record. Kinds: litigation, anticipated litigation, audit, investigation, public-records request, and other authority. Every hold includes an authority reference and reason. Create/release history is append-only; changing a hold atomically replaces it with an attributed successor. There is no expiry that silently releases a hold.
• Service authorization is checked inside each read/write transaction. Typed scope resolution and active-hold matching are shared with later disposition execution; no heuristic matching.
• Dedicated retention services, HTTP adapter, and web page/components. Extract shared API transport into its own owner with compatible legacy imports before adding retention client functions, a focused refactor(web): split large workflow pages and domain API contracts #59 slice.
• ADR and operator documentation identify the exact supported contracts and state that disposition execution/export changes remain in Milestone 5 slice 3: retention, holds, and lawful disposition #64. Existing finalized immutability is untouched.

Acceptance criteria

• Explicit authority grant/revoke is audited, no existing or future role bundle grants it automatically, unauthorized reads and mutations refuse typed.
• Policies retain all superseded versions unchanged; stale replacement refuses; invalid class/trigger/duration/action combinations are rejected by service and schema.
• Holds can be created, replaced, and released through the UI with full attributed history. Applicable installation/enrollment/record holds are resolved exactly.
• Concurrent changes, rollback, raw mutation guards, and revoked-authority boundaries have integration proof.
• Browser scenario proves authority administration, policy versioning, hold replacement/release, and denied access.
• Full CONTRIBUTING.md gates pass; docs/source map/roadmap link to the new owners and remaining Milestone 5 slice 3: retention, holds, and lawful disposition #64 work.

Closes no destruction, recovery, or portable-format acceptance criteria by implication. Refs #44, #64, #59.