[c-RCP-AUDIT-04] Add tc18_master_id to .fusa-reqs.json entries (blocked on master-catalog rebuild)

[SoundMatt]

Background

RELAY's docs/RCP-ARCHITECTURE.md (canonical choice #6, .fusa-reqs.json schema) specifies a tc18_master_id field on every requirement — the id of the corresponding entry in a 640-entry master TC18 requirement catalog spanning all four RCP implementations, so cross-repo reconciliation becomes an exact-match lookup instead of a line-range-overlap heuristic.

As of 2026-08-07, 0 of c-RCP's 1023 requirements have this field — it was never actually added anywhere, even in c-RCP, the repo the rest of the schema (id/title/text/standard/level/asil/scope/status/tc18) is modeled on.

Why this is blocked, not just undone

The master catalog itself (the 640-entry canonical list tc18_master_id values would reference) was scoped and built once earlier in this project's history but was not preserved — a prior attempt to locate it (tc18_master_requirements.json, expected under a session scratch directory) found the file no longer exists; it was likely cleaned up between sessions. Propagating that catalog into all four repos was separately estimated at ~24 remaining scope×repo batches and was never executed — the more targeted SHOULD/MAY extraction effort superseded it as the more immediate ask at the time.

This issue cannot be started productively until the master catalog exists again (either recovered or rebuilt) with stable, cross-repo-referenceable ids (e.g. TC18-11.3-006 style). Rebuilding it is real work in its own right — a full pass over TC18 sections §10 through §13.7.13, assigning one stable id per MUST/SHOULD/MAY clause/table/figure — and should probably be its own issue/session, not folded into this one.

What needs to happen (for the agent picking this up)

1. First, confirm whether a master catalog already exists in this ecosystem by the time this issue is picked up (check other RELAY/x-RCP session state, or ask the user) — do not assume it's still missing without checking, this document may be stale by the time you read it.
2. If it needs rebuilding: work section-by-section through TC18, assign one stable id per normative clause, cross-reference against all 4 repos' actual .fusa-reqs.json files (not just c-RCP) to keep ids consistent cross-repo from the start — this is explicitly a 4-repo effort, not a c-RCP-only one, even though this issue is filed against c-RCP.
3. Once the catalog exists: for each of c-RCP's 1023 requirements, find its corresponding master-catalog entry (most should already have a tc18 citation from issue [c-RCP-AUDIT-02] Backfill TC18 citations on ~801 uncited requirements #164's backfill, which makes this a more mechanical lookup than deriving from scratch) and add the tc18_master_id field.
4. Verify with a freshly-built, CI-pinned cfusa: this is a purely additive field, should not affect check/trace output at all (already confirmed this class of tool tolerates unrecognized/new JSON fields without error) — but verify directly for this specific field rather than assuming.

Not in scope for this issue

• The master catalog rebuild itself is arguably a separate issue/tracking item spanning all 4 repos — whoever picks this up should decide whether to split it out rather than scope-creep this c-RCP-filed issue into a 4-repo effort.
• Issue [c-RCP-AUDIT-02] Backfill TC18 citations on ~801 uncited requirements #164 (citation backfill) should generally land first — tc18_master_id is much easier to add once tc18 citations already exist for most requirements.