gen (Zig): a trailing @panic statement is emitted as return @panic(...), which Zig rejects as unreachable code #7533

Found while porting the A64 encoders (#7531, port epic #6198, self-host #5980).

A fn whose last statement is @panic(...) is lowered by t27c gen to return @panic(...);. Zig rejects it as unreachable code, so the spec is BLOCKED, not tested. In specs/tri/t27b/a64.t27 the panic had to move into an if branch with a value-returning tail.

Minimal repro:

module gap_trailing_panic;

pub fn pick(x: u32) -> u32 {
    if (x == 0) {
        return 7;
    }
    @panic("x must be 0");
}

test pick_zero {
    assert_eq(pick(0), 7);
}

t27c test-report (built from bd3bdcd, near master):

BLOCKED  does not compile: spec.zig:22:5: error: unreachable code

The generated line is return @panic("x must be 0");. Expected: a @panic statement stays a statement (@panic("...");), since it is noreturn and needs no return.

User Scenarios

• Given a T27 function whose last statement is @panic(...), when t27c gen emits Zig code, then the @panic remains a statement (@panic("...");) without a return prefix.

Requirements

• FR-001: The Zig backend MUST emit a trailing @panic call as a standalone statement, not as return @panic(...);.
• FR-002: The generated Zig code for a function ending in @panic MUST compile without "unreachable code" errors.

Success Criteria

• t27c test-run specs/tri/t27b/a64.t27 exits with exit 0 (the A64 spec compiles and its tests pass)
• A minimal repro module with a trailing @panic compiles and runs under t27c test-report with exit 0

Boundary

• specs/tri/t27b/a64.t27