docs: stage 3 missing conditional-request field requirements

[SoundMatt]

Summary

• Investigated the `REQ-SEQ-*` cluster (Compound/CompoundWait/Triggered/Timed/Chained/Cancel) against TC18 §11.2.2/§11.2.3 directly, prompted by its 12-requirement count looking thin next to c-RCP's 89 across the equivalent categories.
• The opcode/routing/state-machine layer is correctly designed (`RequestTypeOpcode`'s 8 real TC18 opcodes, mtv=false repurposing, `expected_start_state`) — this is not the same class of defect found in go-RCP's equivalent layer.
• Three field-level behaviors are genuinely absent (confirmed by grepping `include/`/`src/` — the real TC18 field names appear only in comments, never as real fields/variables/consumed values):
  • Compound: `cmp_exec_delay`/`cmp_repetitions` undecoded and unenforced.
  • Triggered: `trigger_source_ep`/`trigger_signal_nr`/`trigger_threshold`/`trigger_exec_delay`/`trigger_repetitions` undecoded — `TriggerRegistry` (a real, working generic signal registry) isn't wired to any specific request's parameters.
  • Timed: `presentation_time` (48-bit gPTP) undecoded — no scheduling/dispatch logic exists anywhere; the opcode has no distinguishing runtime behavior from a standard request.
• Per this session's discussion: RELAY §20.1.2 hard-gates 100% requirement traceability in CI, so these can't go into `.fusa-reqs.json` directly without either breaking the gate or being real (implemented + tested) — neither is true yet. Staged in a new `.fusa-reqs-pending.json` instead (same schema, confirmed not read by `cpfusa` at all), to be migrated in once each gets a real implementation + test.
• No code change.

Test plan

• `cpfusa check` — 0 errors, output unchanged with the new file present
• `cpfusa trace` — output unchanged (only pre-existing HLR/LLR warnings)