linker_messages=allow removal would silently break macOS/arm64 builds again (no CI coverage)

[bug-ops]

Description

PR #5960 (fixing #5894/#5895) added linker_messages = "allow" to [workspace.lints.rust] in the workspace root Cargo.toml to unblock plain cargo build/cargo run on macOS/arm64 (Apple ld's __eh_frame section too large warning was being denied by build.warnings = "deny", #5891).

This lint only fires on macOS's linker; Linux CI runners never emit the warning, so linker_messages = "allow" is a no-op there. If a future change accidentally removes or narrows that line, CI stays green — nothing in the test/lint/build matrix would catch the regression. It would only resurface when a developer or live-tester next builds on macOS/arm64, exactly the silent-failure pattern #5895 itself was.

Expected Behavior

A regression that reintroduces the eh_frame build failure on macOS/arm64 should be caught automatically, not discovered by a human hitting a broken cargo build.

Suggested Fix (not yet scoped — needs owner decision)

Options, non-exclusive:

1. Add a macOS runner to the CI build matrix (heavier, but closes the blind spot for this and any other macOS-only issue).
2. A lightweight guard test (e.g. a #[test] or build script check) asserting the workspace lint table still contains linker_messages = "allow", so at least accidental removal is caught even without a macOS runner.
3. Accept the residual gap and document it explicitly as a known limitation.

Environment

• Introduced by: PR fix: resolve build.warnings gate fallout from #5891 migration #5960 (closes local pre-commit rustdoc/check gate now fails on 37 pre-existing warnings after #5891 build.warnings migration #5894, plain cargo build/run fails on macOS/arm64: build.warnings denies linker eh_frame warning #5895), commit range starting 02aaedc8
• Original finding: rust-critic adversarial review during fix: resolve build.warnings gate fallout from #5891 migration #5960's implementation (finding M1)