Better UX for pinning an accepted compose

`aci verify|send|serve|audit --accept-compose ` pins the compose hash measured into RTMR3, which is the corroborated value to pin (`repo_url`/`repo_commit` are not bound into the quote, spec §4.1). It works, but it asks a lot of the operator: read a 64-hex value out of a transcript, and re-pin on every legitimate upgrade — certificate pinning's failure mode, and the reason pins get switched off.

Worth building, roughly in order:

- **Trust on first use.** Record what was seen (`--pin-file`, like `known_hosts`) and fail loudly when it changes. This is what most people actually want: not "I know which build is right" but "tell me if it changes under me". An intended upgrade is then one line to accept.
- **A verifier policy file instead of flags** (spec §1.3): accepted composes, subjects, KMS roots, required claims, session pinning, failure mode. Reviewable, shareable, diffable. Flags do not scale past a value or two, and a security policy that lives in shell history is not one.
- **Source-derived acceptance.** "Accept anything built from repo X at a commit I reviewed" is the real answer; it needs the compose reproducibly derivable from the published provenance.

Related: `docs/reviews/aci-spec-conformance-gaps.md` item 2 (provenance is measured, not rebuilt).

Start with the aci verify, send, serve, and audit entry points and the existing --accept-compose behavior described here. Read docs/reviews/aci-spec-conformance-gaps.md item 2 and spec §§1.3 and 4.1. Done requires choosing and specifying one pinning or policy approach, then implementing it with operator-visible upgrade and failure behavior.

Written by the indexing model from the issue text.