Zig backend: `1 << n` is lowered as `@as(u32, 1)` regardless of the declared type (33 files)

[gHashTag]

Found while measuring #2951 with a deeper ruler than the corpus harness uses.

zig build-obj resolves identifiers but never Sema-analyses function bodies that
nothing references, so this defect is invisible to the gate the corpus runs. Under
zig test --test-no-exec it is the reason 32 of the 60 files unblocked by the
assert_eq shim still do not compile.

The shape

var half: i32 = @as(u32, 1) << @intCast(d);   // specs/ternary/gft_add_rne.t27, fn on_comb

The 1 << n lowering hardcodes @as(u32, 1) for the left operand instead of the
declared type of the destination. Assigning a u32 expression to an i32 is a
type error.

Measured

• 33 of 581 generated files emit this shape.
• All 33 sit inside the 60 files that Zig backend: assert_eq is emitted but never declared (60 of 581 files) #2951 unblocks — the undeclared assert_eq
  was masking this today, and after Zig backend: assert_eq is emitted but never declared (60 of 581 files) #2951 lands build-obj's laziness will keep
  masking it.
• Pinning the first error line of each of the 32 files that the shim "loses":
  0/32 blame the shim's own comparison, 32/32 blame emitted function-body code.

Why this is worth its own issue

The corpus acceptance column will not move when this is fixed, because the column
is measured with build-obj. The gain shows up only under a ruler that analyses
bodies. A fix here should be measured with zig test --test-no-exec, per spec,
both directions — and the ratchet that guards it should say which ruler it used.

Refs #2951