check_release_plane.py: generalise FIELD to catch status: in the fields bag too (6 live cases) #375

The defect

tools/check_release_plane.py (landing in #373, for #370) catches release: assignments buried in the fields: extension bag, where rivet's query surface is blind to them. It works, and it is structurally general — but the field it checks is a hardcoded module-level constant:

FIELD = "release"

The same defect exists right now on status:, and nothing catches it.

Measured evidence

While migrating #371 I reconciled 303 raw status: text matches against rivet's 276 reported errors. The 27-item gap is entirely two blind spots:

The six are ARCH-026, ARCH-027, ARCH-028, ARCH-030, ARCH-031, ARCH-032. Each carries fields.status: planned at 6-space indent, sibling of rationale: and source-files:, and has no artifact-plane status at all. That is precisely #370's shape, one field over.

They are not errors today only because rivet cannot see them. They also did not appear in #371's 276, which is why #371 left them in place and named them rather than silently absorbing them.

Proposed fix

Generalise FIELD to a list — ("release", "status") — and iterate. The parser, the block-scalar handling, the fail-closed behaviour and the fixtures are already field-agnostic; only the constant and the report strings assume a single name.

This was deliberately not done inside #371/#374: that branch is stacked on #368, and touching #373's tool there would have stacked it three-deep and broken the "vocabulary only, no tooling change" scope posted on #371.

Second, separable problem

safety/requirements.yaml holds 21 off-vocabulary statuses and rivet never loads it. A plane-checker will not help — the file is outside the store entirely. Either add it to sources: (and then fix what surfaces), or delete it if it is genuinely dead. It should not keep sitting there looking like tracked traceability while being tracked by nothing.

Ordering

Blocked on both #373 and #374 merging.