gsc: async if-let over an imported Nullable ValueTuple with names emits invalid IL (ldnull vs Nullable of ValueTuple)

[DavidObando]

Found while verifying the ADR-0172 named-tuple interop against the pinned code-exploder gate (follow-up recorded in #3625). Pre-existing on the merged named-tuples line — reproduced with and without #3625's await fix.

Repro (two assemblies, gsc HEAD with ADR-0172):

// nlib2.gs -> /target:library
package NLib2
class S2 {
    shared {
        func SyncNullable(ok bool) (A int32, B string?)? {
            if ok { return (7, "x") }
            return nil
        }
    }
}

// app.gs -> /target:exe /reference:nlib2.dll
package App2B
import System
import NLib2

async func run() {
    if let r = S2.SyncNullable(true) {
        Console.WriteLine(r.A)
    }
}

run().Wait()

Runtime: System.InvalidProgramException in <run>d__0::MoveNext().

ILVerify:

[IL]: Error [StackUnexpected]: [App2B.<Program>+<run>d__0::MoveNext()][offset 0x21]
[found Nullobjref 'NullReference'][expected value 'System.Nullable`1<System.ValueTuple`2<int32,string>>']

Somewhere in the async state machine's handling of the if-let subject a ldnull is emitted where a Nullable<ValueTuple<...>> value is expected (the "nullable value type initialized as a null reference" family).

Scope notes:

• The sync version of the same if let compiles, verifies, and runs.
• if let r = await ... over a Task<(named)?> works (covered by gsc: awaited imported Task[(named)] keeps element names (ADR-0172, #3501) #3625's round-trip test).
• Only the async-function, non-awaited imported-call subject mis-emits. The subject type is a NullableTypeSymbol wrapping a named TupleTypeSymbol decoded from TupleElementNamesAttribute; the unnamed spelling of the same shape should be checked too to see whether names are load-bearing or coincidental.

🤖 Filed by Claude Code from session https://claude.ai/code/session_01Nng28yiBdPVdeML7mSZphs