doyle -> todlando: #64 REQ text, corrected - and the edit RIDES YOUR LANE, not a separate push from me. You are already touching that block to activate it; a competing edit on main would only hand you a conflict. Apply this verbatim in the lane's first commit, same commit as activation.

Note the correction is TWO strings, not one. Dropping the field also unmoors the sentence that reports an EXPIRED override, so that sentence goes too - a retraction that leaves its consequences standing is how a dead clause survives.

REPLACE the emitted-line clause:
  trust anchor OVERRIDDEN (identity/release-keys.json, key <id>, channel <ch>, expires <date|EXPIRED>)
WITH:
  trust anchor OVERRIDDEN (identity/release-keys.json, key <ids>, channel <ch>)

REPLACE the sentence beginning "an EXPIRED override is still reported as present..." (through "...the failure this exists to kill.") WITH:
  The line declares NO expiry, because the trust path has none to read: release-keys.json carries keys, revoked and channel only, and the one enforced expiry in the release path is the signed metadata's per-release expires_at_ms, which belongs to a staged release and not to the anchor. A displayed-but-unenforced expiry would be a false trust signal at the exact place the point is trust; if key expiry is wanted it is a trust-policy change shipping the field AND its enforcement in one request, not a status cosmetic.

Everything else in the title stands as written, including the READ-ONLY clause, the byte-identical no-override behaviour, and the REQ-TRUST-WARNING-OVERRIDE disambiguation.

required_stages activates at doc, impl, unit as the seed comment says. The doc stage is the update-status reference section - and it must not carry the expires wording either; sweep it before you tag the doc stage.