spec(port): port the header extension order guard (Refs #8884)

[dmitrii-f-t27]

Refs #8884 (CR-CHAT-04 ring tracker). Parent epic: gHashTag/trios#1812 (W2, own lane, T-PORT).

Target delivered

• specs/port/trios/crates/trios-chat/rings/CR-CHAT-04/src/header_extension_order_guard.t27 from crates/trios-chat/rings/CR-CHAT-04/src/header_extension_order_guard.rs @ 8b229e9489ee (200 lines: 1 pub fn, 4 consts, 2 types, 10 tests HEXO-01..10, 6-variant HeaderExtError)

How the port follows the conventions

• Verdict: D5 named struct (HeaderExtVerdict), Ok first, error variants in the original's declaration order, the offending type_id carried for every variant that has one. Rule order is the original's, bit for bit: batch bound, then per extension the type floor, payload non-empty, payload ceiling, duplicate, ascending order.
• The original's Option<u16> previous-type reference becomes a has_prev flag plus the value; the Vec<u8> payload is only ever read by length in the decision, so the record carries payload_len (a length, not the bytes - no secret or payload content reaches the spec).
• Every original #[test] transcribed with exact verdict asserts (HEXO-01..10), plus a rule-order test and a HEXO_MAX_TYPE boundary test; 12 tests total, 0 vacuous.
• Loop fixtures (17- and 16-extension batches) read their type IDs from const u16 tables - no narrowing cast anywhere in the file, so the native backend lowers every construct: the whole spec passes under t27b, measured.
• Constants re-declared with their original types; ASCII only; full module line.

Checks (t27c and t27b built from this tree, Zig 0.16.0, rustc 1.98.0)

gate	result
t27b test (native)	12 passed, 0 failed
t27c test-report	12/12, 0 FAIL, 0 vacuous
spec-status / gen	IMPLEMENTED / 0 unimplemented
gen-rust + rustc --edition 2021	exit 0, 0 &'static str, 0 Vec<const
coverage	Untested: 0
seal --save + --verify	all hashes MATCH

Ledger: measured t27b pass - this PR adds the expectations-ledger row in the same hand-edit form as #9614, or the steward's next bless picks it up.

Check 0 (dedup): no open PR, no feeder issue, no spec on master for this stem.

Not done here: the trios-side swap (waits on the W0 pilot); the remaining targets of #8884.

[dmitrii-f-t27]

Merge request for the gHashTag merger + one sequencing note.

Steward verdict on the final SHA 9c0e937: READY (required checks all SUCCESS; the three red — cli-tri, duplicate-bodies, t27b-native-ratchet — are non-required per Q16, red on master too; this PR's own ratchet rows are gone — its ledger row landed in the last commit, and the two padding rows it still reports come from the unmerged #9614's subjects, not from this PR).

Sequencing: merge t27#9614 first — it repairs the two ratchet rows that #9613 added on master. Then this PR: its one ledger insertion sits in the same gap as #9614's two, so if #9614 merges first this branch needs a one-line rebase of the ledger file — I will rebase and re-push the moment #9614 lands (or the merger can merge this one first and #9614 rebases instead; either order works, both files are one-line JSON rows).

Progress note in the ring tracker: the third W2 target delivered, specs + seals measured, t27b pass natively.

[gHashTag]

Carried unchanged, with its original author, as one commit of #10097 (tracking #10096). That PR lands all 25 green CR-CHAT-04/07 ports at once, because each single PR kept conflicting on the ledger rows before its CI could finish. Closing this one so its queued jobs free the Actions queue.