fix(safety-docs): correct ASIL declaration + RxSequenceGuard/Zone-model staleness

[SoundMatt]

Fixes three confirmed HIGH findings from the cpp-RCP v3.0.0 deep audit, verified individually against source before editing.

Finding A — .fusa.json project ASIL contradicted .fusa-hara.json

.fusa.json's project.asil was ASIL-B, but .fusa-hara.json's H-001 (and its safety goals SG-001/SG-003/SG-007) are ASIL-C, and HARA.md's H-001 rationale explicitly states no decomposition is claimed — S3/E4/C2 maps to ASIL-C directly.

Fix: .fusa.json's asil/project.asil corrected to ASIL-C.

Tooling bug discovered en route: the pinned cpp-FuSa v0.18.0 binary's config loader (src/config/config.cpp) only reads a top-level asil/standard key — never the nested project.asil/project.standard this repo's .fusa.json schema used. So HARA005 was silently falling back to the tool's own hardcoded "ASIL-B" default regardless of what project.asil said; the previous ASIL-B value only ever "matched" that default by coincidence. Confirmed by editing only the nested field first — cpfusa check still printed HARA005: Hazard ASIL ASIL-C exceeds project ASIL ASIL-B. Fixed by adding top-level asil/standard fields (matching cpp-FuSa's own dogfooded .fusa.json) alongside the existing nested ones.

Verified: cpfusa check now reports [iso26262/ASIL-C] and HARA005 no longer fires (0 errors, 1 pre-existing unrelated warning — FUSA004, missing evidence file, expected without a test run).

Docs updated (project-wide "target ASIL" statements only, each with a one-line justification citing HARA.md/H-001): README.md, AUDIT_PACK.md (doc metadata + intro sentence only — see follow-ups), TARA-ANALYSIS.md, SAFETY_PLAN.md.

Left alone (narrowly-scoped, correctly ASIL-B per .fusa-hara.json): SG-002/004/005/006/008/010/011.

Flagged as ambiguous, deliberately not changed: README.md's per-header "(ASIL-B)" design-pattern labels (watchdog.hpp/redundancy.hpp rows), INCIDENT-RESPONSE.md's "ASIL-B requirement violation" severity example — neither clearly asserts the project's own target ASIL.

Not touched: safety-case.json/md, sas.json/md, sci.json, fmea.*, tooling/tara.* — these are regenerated by cpfusa safety-case/etc. on every tagged release (release.yml) via a bot PR and will pick up the corrected ASIL automatically; hand-editing would just be overwritten.

Finding B — HARA.md/FORMAL_VERIFICATION.md said RxSequenceGuard was unwired; it's been wired since Phase 4 batch C

Verified directly against include/rcp/mock.hpp: Server holds a seq_trackers_ member (std::array<e2e::RxSequenceGuard, ...>), and both dispatch_e2e() and dispatch_frame_e2e() call it via a shared seq_gate_admits() helper on every dispatched request/frame before CRC unwrap — integration-tested in tests/test_mock.cpp, not just RxSequenceGuard's own standalone tests/test_e2e.cpp unit test. include/rcp/e2e.hpp's own "UPDATE (Phase 4/Phase 17 batch C...)" file-header comment corroborates this as the authoritative account.

Fix: updated HARA.md's SG-004 row, full H-004 section, and its Residual Risks row from "not wired"/"effectively Open" to the current "Mitigated (opt-in)" state (matching c-RCP's own disposition for its equivalent mechanism) — while being explicit this covers mock::Server's own reference dispatch; a caller driving a transport Server with fully custom dispatch logic instead of wiring mock::Server::dispatch_frame()/dispatch_frame_e2e() as the FrameHandler isn't automatically covered (per udp.hpp/l2.hpp's own header notes). Updated FORMAL_VERIFICATION.md's SP1/SP2 point 1 to match; left point 2 (the TLA+ spec modeling the pre-RFC-1982 algorithm — a separate, still-true, still-open issue) untouched.

Did not change H-004's S2/E3/C2/ASIL-B classification or claim anything about coverage/testing beyond what mock.hpp/test_mock.cpp actually show.

Finding C — SAFETY_PLAN.md still documented the retired Zone/Command/Controller model

Verified all five dead requirement ids (REQ-CTRL-025/026/027/004, REQ-ERR-011) are absent from .fusa-reqs.json, .fusa-reqs-pending.json, and include/.

• "Zone mismatch detection" → repointed to REQ-MOCK-010 ("dispatch to an unmapped byte_bus_id reports invalid_parameter"), the real current endpoint-addressing-validation mechanism, matching HARA.md's SG-002 "Addressed By" entry.
• "Deadline monitor" row's description reworded to drop stale "zone"/"Config.Deadline" wording (REQ-DL-002 id was already correct).
• "Payload copy-on-send", "Payload copy-on-publish", "Context / deadline propagation" (also citing dead ids, named in the finding but not walked through in its concrete fix guidance): verified no current analog exists for any of the three in the stream/endpoint/register-map wire-protocol architecture. Marked "No direct analog" per instructions rather than inventing a false mapping.
• Also fixed the Safety Goals table in the same document (SG-001/003/007 ASIL-B → ASIL-C per .fusa-hara.json, part of Finding A; "Commands"/"CmdWatchdog"/"Dead zone" terminology retired, part of Finding C) since it sits directly above the mechanisms table and shares the identical root causes.

Verification

• python3 -c "import json; json.load(open('.fusa.json'))" — passes.
• cpfusa check — HARA005 gone; 0 errors, 1 pre-existing unrelated warning.
• cpfusa lint — 146 warnings both before and after (git stash diff) — unchanged, confirming no new findings from these doc/JSON edits.
• cpfusa trace — pre-existing dangling-test-tag/no-LLR-children warnings only, all in tests/*.cpp, unrelated to and untouched by this batch.

Follow-ups flagged, not resolved by this pass

• AUDIT_PACK.md §2's ASIL-D gap-analysis derogation table and its ASIL-B(D) = ASIL-A + ASIL-B decomposition math predate the ASIL-C correction and need dedicated safety-case re-derivation (flagged in-document with an explicit note).
• AUDIT_PACK.md §3's "ASIL-C upgrade path"/"80% ASIL-C target" MC/DC wording now reads oddly against a project that already targets ASIL-C; left untouched since the underlying coverage-gap facts are unaffected and touching MC/DC threshold language felt too far outside a documentation-consistency fix.
• .fusa-hara.json itself has a latent, separate inconsistency discovered while reading it for this batch: H-003 and H-005 are rated ASIL-B as hazards, but their own safety goals SG-003/SG-007 are rated ASIL-C. Out of scope for these three findings; noted for a future pass.
• No new requirement ids were invented.

This closes 3 findings from the cpp-RCP v3.0.0 deep audit.