Fix for follow-up #2 from step 2b. When a pack-fn declares
`(..\$args) -> \$R` (return type a generic name), the mono now
infers ret_ty from the body's first explicit `return X;` or
falls back to the tail expression of an arrow-form body.
Plumbing in src/ir/lower.zig:
- `inferPackBodyReturnType(body)` walks the body via the
existing `findReturnValueType` helper (return stmts) and
falls through to `inferExprType` on the tail expression for
arrow-form / tail-expr bodies.
- `monomorphizePackFn` now pre-installs `pack_arg_nodes` and
`pack_param_count` BEFORE resolving the return type so the
inference can substitute `args[<lit>]` to call-site arg
AST nodes during type lookup.
- Generic-ret detection: `fd.return_type` AST node is a
`type_expr` with `is_generic = true`. Concrete returns stay
on the standard `resolveReturnType` path.
`examples/159-pack-generic-ret.sx` flips from `0 0` (silent-
zero coercion through opaque struct ret_ty) to `42 99`.
198/198 example tests + `zig build test` green.
Follow-up #2 from step 2b: pack-fns with a generic return type
(`(..\$args) -> \$R`). Today's `monomorphizePackFn` calls
`resolveReturnType` which sees `\$R` as a generic name and
returns an opaque struct TypeId. The mono's ret_ty is wrong
and the value silently coerces to 0.
`examples/159-pack-generic-ret.sx` pins this: `first(42)` and
`first(99)` both return `0` instead of the call arg. The lock-in
captures the wrong output as the snapshot to flip.
Next commit infers the ret type from the body's tail expression
(arrow form) or the first explicit `return X;` (block form),
then builds the mono signature against that concrete type.
198/198 example tests + \`zig build test\` green.
