rewrite(phase6): batch 11 — REQ-REGMAP-*→REQ-RMAP-* rename + RMAP/SRV catalog

[SoundMatt]

rewrite(phase6): batch 11 — REQ-REGMAP-→REQ-RMAP- rename + RMAP/SRV catalog

Part of the v3.0.0 ground-up rewrite (cpp-RCP #129, ROADMAP.md Phase 17),
branch rewrite/v3-from-c-rcp. Phase 6 (requirement catalog), batch 11 of 13
-- the largest single batch so far, combining a real id-field rename with
two full-prefix derivations.

Part A — REQ-REGMAP-* → REQ-RMAP-* rename

Pure id-field rename per ROADMAP.md Phase 17's already-established
canonical naming (RELAY's docs/RCP-ARCHITECTURE.md cites REQ-RMAP-* as
canonical): all 15 REQ-REGMAP-001..015 catalog entries renamed to
REQ-RMAP-001..015 (id field only, no other field changed), plus all 15
code tags in include/rcp/regmap.hpp and 36 test tags in
tests/test_regmap.cpp. severity:cybersecurity preserved on all 15
(these are part of the enumerated 72-id cybersecurity subset per
ci.yml's own comment) -- sec-tested count holds at exactly 72. Zero
REQ-REGMAP-* remnants anywhere in .fusa-reqs.json, .fusa-reqs-pending.json,
or the include/+tests/ tree (one pre-existing entry's own prose text
still literally says "REQ-REGMAP-005" referring to another entry by
name -- left untouched, it's descriptive text, not an id). Stale
REQ-REGMAP-* mentions remain in CYBERSECURITY.md/TARA-ANALYSIS.md/
ROADMAP.md/ci.yml's comment -- outside this batch's scope, left for a
docs pass; the CI gate itself reads the severity field dynamically, not
a hardcoded id list, so it's unaffected.

Part B — REQ-RMAP-* full derivation (87 c-RCP entries)

• 59 new catalog entries (016-045, 047-058, 060, 066-067, 070-071,
  073-079, 082-084, 086-087), including 055 (already fully tagged in
  lifecycle.hpp/test_lifecycle.cpp from an earlier batch -- cross-module
  mapping, no code touch) and two status:partial entries (023, 067)
  honestly preserved from c-RCP.
• 15 id-collision/gap entries filed to .fusa-reqs-pending.json:
  001/002/003/009/010/011/012/013/014/015 -- the rename claimed these
  numerals first for cpp's own pre-existing content; c-RCP's real
  content at the same numbers (is_ep0(), writer_ctx() grant/withhold,
  hw_pin bit-layout distinctness, named_signal_string()) is separately
  implemented+tested, filed as collisions rather than corrupting id
  uniqueness -- matching the established pattern from batches 6-10.
  068/069/072/080: real gaps matching regmap.hpp's own explicit
  "EP0 address-routed dispatcher NOT ported in this batch" scope note.
  081: genuine TC18 spec-defect gap (EP_RESP_ON_ERROR, a Table 31 prose
  reference with no defined bit/field) -- matches c-RCP's own
  not-implemented disposition verbatim; cpp additionally has a
  defensive test proving no bit is invented for it.
• 6 retired ids (004-008, 046) -- c-RCP itself retired these
  (superseded by 030/039); no entry or gap filed, since there's no real
  c-RCP content for cpp to collide with or gap against.
• 15 renamed + 7 pre-existing respqueue-specific (untouched) + 59 new +
  15 pending + 6 retired = all 87 c-RCP ids accounted for.

Part C — REQ-SRV-* full derivation (42 c-RCP entries, all new)

include/rcp/server.hpp already carried all 42 fusa:req tags from an
earlier untracked pass -- zero code edits needed there (0 line delta).
tests/test_server.cpp only had 24 of 42 tested; added 14 new TEST_CASEs
plus several dual-tags to close the remaining 18 (019, 020, 022,
024-034, 037-039, 042), including genuinely new coverage for per-kind
select_due() gating (027-032), CompoundWait's independent per-slot
evt/payload evaluation and wait_tick() application (020, 033, 042),
no-sequencer-advance-for-Triggered/Timed/Chained plus always-removed
(034, 037), and chain-timer-not-restarted (038). All 42 SRV catalog
entries added.

No new entry (RMAP or SRV) carries severity:cybersecurity -- confirmed
neither c-RCP's real 87 RMAP nor 42 SRV entries mark any as
security-relevant; sec-tested count unchanged at exactly 72.

Verification

Independently re-verified (not just the porting agent's own report,
which itself ran a whole-catalog tag-coverage script twice, catching
and fixing one gap where REQ-RMAP-082 had a test tag but no fusa:req
tag before finalizing): semantic id-keyed diff confirms zero
pre-existing entries modified, exactly 116 new/renamed ids (15 renamed

• 59 new RMAP + 42 new SRV) matching the report's breakdown exactly,
  zero duplicate ids anywhere (catalog or pending). Independently
  re-derived the whole-tree tag-coverage check from scratch in Python
  against the merged worktree (not trusting the agent's script alone):
  confirmed all 1076 entries have both a real fusa:req and a real
  fusa:test-or-bracket tag somewhere in include/+tests/, zero gaps.
  Confirmed severity:cybersecurity was preserved on exactly the 15
  renamed entries and granted to zero genuinely-new entries -- sec-tested
  count holds at exactly 72/1076. Directly spot-checked the REQ-RMAP-009
  writer_ctx tag placement, the REQ-RMAP-081 spec-defect gap text, and
  the new REQ-SRV-027/028/033 select_due()-gating tests against the real
  diff -- all confirmed accurate. Full tree rebuilt from scratch: 0
  errors, 0 warnings, 58/58 ctest suites pass (100%).

.fusa-reqs.json: 975 -> 1076 entries (+116, well over +101 in raw
additions once the 15 rename removals are netted out; 10288 -> 11498
lines). .fusa-reqs-pending.json: 108 -> 123 entries (+15, 1226 -> 1420
lines). include/rcp/regmap.hpp: +11 lines net (rename tags only).
tests/test_regmap.cpp: +23 lines net (rename tags + dual-tag
additions). include/rcp/server.hpp: unchanged (0 line delta).
tests/test_server.cpp: +339 lines net (14 new TEST_CASEs + dual-tags).

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com