Iter 16b.5: LetRec name as value (in_term only) via eta-Lam wrapper

Drops the direct-call-only restriction on the LetRec name when it
appears in `in_term`. No new ABI: the lift wraps the in-term in
`(let f (lam P (app f$lr_N P CAPTURES)) in_term')` so codegen's
existing Iter-8b closure-pair machinery handles it. Body-position
name-as-value still rejected (deferred — eta-of-self is harder).

- desugar.rs / lift.rs: split find_non_callee_use into body
  (panic) and in_term (wrap).
- examples/local_rec_as_value.{ailx,ail.json}: no-capture path
  (factorial passed to apply5 → 120).
- examples/local_rec_as_value_capture.{ailx,ail.json}: capture
  path; lifted fn has captures, eta-Lam picks them up via 8b.
- e2e + desugar tests: 113 → 116 (+3).

Codegen Lam machinery handled the wrapped form on the first try.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/JOURNAL.md

@@ -4005,3 +4005,161 @@ strictly-nested non-mutual case but the mutual case needs joint
 lifting). 16d (chain-machinery exhaustiveness or
 `__unreachable__`), 16e (`==` extension to Bool/Str/Unit),
 17a (per-fn arena, gated) unchanged.
+
+## Iter 16b.5 — LetRec name as value (in_term only) via eta-Lam wrapper
+
+**Goal.** Lift the "callee-only use of the LetRec name" restriction
+for the **in-clause** of a `(let-rec ...)`. After this iter, the
+LetRec name `f` may appear in `in_term` as a value (e.g. passed to
+a higher-order combinator, bound to another `let`, stored in an ADT
+field). References to `f` as a value INSIDE the LetRec's own body
+remain rejected — that case has a chicken-and-egg with the call-site
+rewrite (the body's bare `f` references would need to call a name
+that doesn't exist before the lift) and is queued as a non-trivial
+extension.
+
+**Architectural choice (no new ABI).** Reuse the closure-pair
+machinery from Iter 8b (`lower_lambda` in `ailang-codegen`). After
+the existing 16b.2/16b.3 capture rewrite produces the lifted fn
+`f$lr_N(p1..pk, c1..cm) -> rt` and rewrites every `(app f a..)` →
+`(app f$lr_N a.. c1..cm)`, the lifter detects whether `in_term`
+contains any non-callee use of `f`. If yes, it WRAPS the rewritten
+in-term in
+
+```
+(let f
+   (lam (params p1..pk) (ret rt) (effects E)
+        (app f$lr_N p1..pk c1..cm))
+   <rewritten in_term>)
+```
+
+The Lam's free variables (the captures `c1..cm`) are picked up
+automatically by the existing 8b capture analysis in
+`lower_lambda`. The Lam's signature mirrors the LetRec's declared
+type, so any non-callee `Var{f}` in `in_term` resolves to a
+`Fn(t1..tk) -> rt ![E]` value — usable wherever the typechecker
+expects that type. Callee-position references in `in_term` are
+already rewritten to `f$lr_N` (no closure indirection at the call
+site; the wrap only affects value-position uses).
+
+The reduction is satisfying: 16b.5 reduces a problem that looked
+like it needed a new ABI to a problem already solved by Iter 8b.
+No closure ABI changes, no codegen plumbing, no LLVM IR change.
+
+**Where the wrap happens.** Two sites — both fast paths can
+encounter LetRecs with non-callee uses in in_term:
+
+1. **`crates/ailang-core/src/desugar.rs`** (~+50 LOC inside the
+   existing `Term::LetRec` arm). The body-side `find_non_callee_use`
+   panic was kept (now points at the body-only restriction rather
+   than the generic 16b.5 deferral). The in_term-side check no
+   longer panics; instead it sets a flag `in_has_value_use`. After
+   the standard call-site rewrite, when `in_has_value_use` is true,
+   the in-term is wrapped in a `Term::Let { name: f, value: Term::Lam,
+   body: <rewritten in_term> }`. The Lam's `effects` come from
+   `peel_forall_to_fn(ty)`. The defensive `subst_var` on `in_term`
+   is dropped — bare `Var{f}` references must reach the new
+   let-binding unchanged.
+
+2. **`crates/ailang-check/src/lift.rs`** (~+50 LOC inside the
+   existing post-typecheck LetRec arm). Symmetric to (1). The
+   wrap is identical in shape. The lift's effects come straight
+   from `ty` (already known to be `Type::Fn` at this point —
+   Forall is rejected upstream).
+
+**What stays rejected.**
+- `find_non_callee_use(body, name)` returns Some → panic with the
+  16b.5 body-only message: "name-as-value of a LetRec inside its
+  own body is not yet supported." Both sites.
+- `EnclosingLetRec` capture (16b.7) — unchanged.
+- Forall-typed LetRec (16b.6) — unchanged.
+
+**Did the codegen Lam machinery handle the wrapped form on the
+first try?** Yes. The eta-Lam is a perfectly ordinary `Term::Lam`
+whose body happens to be a single `Term::App` to a top-level
+synthetic fn with the lam's params + free-var captures appended.
+8b's `collect_captures` walks the Lam body, sees `f$lr_N` in
+top-level fns (it's been pushed to `module.defs` already), sees
+`p1..pk` in `bound`, and classifies the remaining `c1..cm` as
+captures — exactly right. No AST massaging was needed. The
+non-capture variant (no extras) reduces to the simplest possible
+Lam (params-only body), which 8b also handles trivially. End-to-end
+ran on first attempt for both fixtures.
+
+**What shipped.**
+
+- `crates/ailang-core/src/desugar.rs`: split `find_non_callee_use`
+  into body-only (panic) and in_term-only (sets a flag, then wraps
+  below). Drop the post-rewrite `subst_var` on the in-term — it
+  would otherwise rename the very `Var{f}` references that need to
+  resolve to the eta-Lam binding. Updated docstring on the
+  pre-existing panic test (`let_rec_name_as_value_panics` →
+  `let_rec_name_as_value_in_body_panics`) and added a new positive
+  unit test `let_rec_name_as_value_in_in_term_wraps_to_eta_lam`
+  that constructs an in_term-side value use and asserts the
+  resulting AST shape (lifted FnDef appended; main's body is
+  `Let { f, Lam{x -> App f$lr_0 x}, <rewritten body> }`).
+- `crates/ailang-check/src/lift.rs`: same split. Drop the
+  defensive `subst_var` on `in_term` when there's a value use;
+  keep it as no-op when there isn't (zero-capture symmetry).
+- `examples/local_rec_as_value.ailx` + `.ail.json`: factorial
+  bound by `(let-rec ...)` inside main, then in the in-clause
+  passed as a VALUE to a higher-order combinator
+  `apply5 : (Fn(Int) -> Int) -> Int`. No captures. Expected
+  stdout: `120` (= apply5(factorial) = factorial(5)).
+- `examples/local_rec_as_value_capture.ailx` + `.ail.json`:
+  variant with capture. `run_with_base(base)` builds a recursive
+  `factorial_plus` that uses `base` in its base case, then passes
+  the helper as a VALUE to `apply5`. The lifted fn is
+  `factorial_plus$lr_0(n: Int, base: Int) -> Int`; the eta-Lam
+  binds `factorial_plus` to a `(lam (n) (app
+  factorial_plus$lr_0 n base))` whose free var `base` becomes a
+  standard 8b closure-env capture. Expected stdout: `1320`
+  (= 5*4*3*2*(1+10)) and `12120` (= 5*4*3*2*(1+100)).
+- `crates/ail/tests/e2e.rs`: `local_rec_as_value_demo` and
+  `local_rec_as_value_capture_demo` (e2e count 41 → 43).
+- `crates/ailang-core/src/desugar.rs::tests`:
+  `let_rec_name_as_value_in_body_panics` (renamed from the
+  16b.2-era panic test; same fixture) and the new positive test
+  `let_rec_name_as_value_in_in_term_wraps_to_eta_lam` (desugar
+  count 10 → 11; net +1).
+
+**Cross-iter regression check.** All five existing LetRec/lit_pat
+fixtures (`local_rec_demo`, `local_rec_capture`,
+`local_rec_let_capture`, `local_rec_match_capture`, `lit_pat`)
+build, run, and produce identical stdout. Their on-disk hashes
+(reported via `ail manifest`) are unchanged because the desugar
+pass runs after `load_module` and never touches canonical bytes.
+
+**Tests: 113 → 116 (+3).**
+
+- e2e: 41 → 43 (`local_rec_as_value_demo`,
+  `local_rec_as_value_capture_demo`).
+- `ailang-core::desugar::tests`: 10 → 11 (one rename + one new
+  positive test). Net +1.
+
+**Cumulative state, post-16b.5.**
+
+- Stdlib unchanged (5 modules, 29 combinators).
+- `Term` enum: 11 variants (unchanged). All pre-16b.5 fixture
+  hashes bit-identical.
+- Compiler stages: load → desugar → typecheck → lift_letrecs →
+  codegen (unchanged from 16b.3).
+- The four `unreachable!("Term::LetRec eliminated by desugar")`
+  arms in `ailang-codegen` are still correct — by the time
+  codegen runs, no LetRec survives. The eta-Lam is a `Term::Lam`,
+  which has its own well-trodden codegen path.
+- DESIGN.md unchanged. Pipeline is unchanged.
+- Compiler bugs surfaced and fixed in dogfood since 14a: 5/5
+  (unchanged).
+
+**Queue update post-16b.5.** 16b.5 done for the in_term-only
+slice. Open: **16b.5-body** (informal — not formally numbered;
+"non-trivial extension" per the orchestrator's brief), where the
+LetRec name is used as a value INSIDE its own body. Solving that
+needs either eta-conversion-of-self (the body's `f` would resolve
+to a fresh Lam built around the lifted callee, but constructing it
+inside the body before the lift completes is order-sensitive) or
+a true closure conversion that doesn't lift to a top-level fn at
+all. **16b.6** (Forall-typed LetRec), **16b.7** (nested mutual
+LetRec capture), 16d, 16e, 17a unchanged.