docs: stabilize Rex4

[Troublor]

Summary

Updates developer documentation to reflect Rex4 as the current stable spec, matching the stabilization in mega-evm (commit c111842).

• volatile-data.md: Replace absolute detention cap with Rex4's relative detention model (20M from point of access); promote "read volatile data late" as primary best practice; remove both <details> "Rex4 (unstable)" blocks
• system-contracts.md: Add MegaAccessControl and MegaLimitControl as full sections with interfaces, outcomes, and spec links; remove <details> "Rex4 preview" block
• overview.md: Update latest hardfork from Rex3 to Rex4; update volatile data cap description to reflect relative detention
• AGENTS.md files: Generalize unstable spec convention (all specs now stable); update capitalization example Rex3 → Rex4

Test plan

• mise run lint passes (0 errors, 0 broken links, formatting clean)
• Verify rendered pages on GitBook preview

[claude]

Overall this is clean and well-structured. Two things to address:

DIFFICULTY + PREVRANDAO listed as separate opcode triggers (volatile-data.md, "Block Environment Opcodes" table)

These are the same opcode (0x44) — post-Merge, opcode 0x44 was repurposed and renamed from DIFFICULTY to PREVRANDAO. Listing both implies 10 separate triggers when there are 9. Consider consolidating to one row, e.g.:

| `PREVRANDAO` / `DIFFICULTY` | Previous RANDAO output (opcode 0x44; the pre-Merge name was DIFFICULTY) |

The interface correctness question is captured in the inline thread on system-contracts.md.

[claude]

Looks good overall. The Rex4 stabilization is clean — relative detention model, PREVRANDAO rename, and the two new system contract sections are all well structured.

One resolved item: the previous thread about view semantics on disableVolatileDataAccess / enableVolatileDataAccess — the explanation added in the Interface section ("The node intercepts these calls and tracks the restriction outside EVM storage") directly answers the concern. Resolved that thread.

One remaining item: the DisabledByParent() error name in the enableVolatileDataAccess() outcome bullet — flagged inline. That's a precise claim worth a quick grep against the mega-evm source before merging.