docs: comment rot cleanup (line-number and PR-decoration references)

[r6e]

Source

Adversarial Phase 1 comment-accuracy audit. Five concrete rot instances + two improvement opportunities. All localized to brittle citation forms (literal line numbers in cross-file references, PR/issue numbers used as decoration rather than semantic anchors).

The audit verdict: wire-format claims, numerical constants, function-name references, and high-stakes Display/Display-test pairings are all accurate. The rot is purely citation-shape.

Concrete rot

1. pak/mod.rs:856-868 SAFETY comment cites wrong issue + literal line range

// SAFETY: structurally unreachable from a successfully-opened
// reader. Issue #82's open-time iteration above (around line
// 222-249) ...

The open-time iteration is attributed by line 183's own header to #58, with the wire_size() correction from #85. #82 is referenced nowhere else in the codebase. The "(around line 222-249)" range is approximately right but rots every time anything above it shifts.

Fix: drop the line range; cite #58 + #85 instead.

2-4. Three fstring.rs:N line refs in index/mod.rs test docstrings point at wrong lines

• index/mod.rs:1006-1011 says LengthIsI32Min arm at fstring.rs:43 — actually at lines 60-67
• index/mod.rs:1032-1036 says UTF-16 missing-null at fstring.rs:71 — actually at lines 89-97
• index/mod.rs:1062-1067 says UTF-16 invalid-encoding at fstring.rs:80 — actually at lines 99-105

Fix: drop the :N line numbers; arm names alone are stable.

5. index/mod.rs:2086 line ref to entry_header.rs is off

// For None, compressed_size = uncompressed_size by line ~327.

Actually at lines 333-337. Fix: replace with name reference (e.g. "per the read_encoded compressed-size dispatch").

Improvements

6. path_hash.rs:326 cites issue #46 for "empirical evidence"

Per memory (feedback_verify_wire_format_claims.md), #46 was a case where reviewers were confidently wrong about a wire-format claim. Pointing readers there is risky. Fix: inline the empirical evidence (one-liner: "verified against <fixture> and trumank/repak's <source-link>"), OR drop the issue reference.

7. error.rs:7-44 layering note's PR #123 lead-in is decorative

"Reviewers in PR #123 surfaced the inversion;" adds nothing the rest of the comment doesn't already explain. The rationale that follows is high-quality and load-bearing. Fix: drop the lead-in clause; the reasoning is self-contained.

Pattern-level guidance

Prefer name references over line numbers; only cite issue/PR numbers when they convey load-bearing context the surrounding prose doesn't.