test-ratchet red on master: rejects_invalid_width_u3 is stale since uN casts were accepted #10320

Boundary

bootstrap/src/compiler.rs, the unit tests_compiler_rejects::rejects_invalid_width_u3, and bootstrap/stage0/FROZEN_HASH. No spec, no codegen, no seal changes.

User Scenarios

• A maintainer opens any PR against master and sees test-ratchet red on one newly failing unit, compiler::tests_compiler_rejects::rejects_invalid_width_u3. The same unit is red on master (run 39110248562), so the red is inherited and hides real regressions in every PR.
• A developer writes x as u3. Since t27c: accept uN casts, 1 <= N <= 64, decided in int_type_names.t27 (Closes #10072) #10084 this is a legal cast (uN, 1 <= N <= 64, decided in specs/compiler/int_type_names.t27), so the unit that expects a compile error is out of date. The contract it guards, that an invalid width is rejected, still holds for u0 and u65.

Requirements

• The unit keeps asserting that an invalid integer width in a cast is a compile error, using u65, which int_type_names.t27 refuses (uint_bits("u65") == null).
• It is renamed rejects_invalid_width_u65; the edit is net-zero lines (shrink-only foreign budget).
• bootstrap/stage0/FROZEN_HASH is recomputed for the edited compiler.rs.

Success Criteria

• rejects_invalid_width_u65 passes on the Railway lab.
• test-ratchet no longer lists rejects_invalid_width_u3.
• tools/check_seal_coverage.py reports no seal drift.

Cause: commit 0a09094, "t27c: accept uN casts, 1 <= N <= 64, decided in int_type_names.t27 (Closes #10072) (#10084)".