Record rc-elision result, refinement roadmap, and the guiding model

Mark the elision built (conservative first cut, the measured incref/decref
reduction), and record the refinements with headroom: proper dominance rather
than the straight-line rule, full dataflow liveness, more elision categories
(return moves, orphan-temp direct frees that attack the untouched allocations,
retain/release cancellation, struct-field moves). Record the guiding model: take
Rust's ownership and borrow analysis as an internal oracle, never a gate, with RC
as the always-correct fallback, so nothing is rejected and the surface stays
invisible. The larger unrealized lever is borrow elision (Rust's shared
reference): a parameter the callee only reads needs no caller retain at all,
which needs a per-function escape summary and is interprocedural.

Author: Axmouth

plans/PROFILING.md

@@ -106,24 +106,52 @@ First result on the http hello server: call-arg retains dominate (72 of the 97 m
 retains) and 55 are movable, so the calling-convention retain (the caller retains, the callee drops)
 is the large lever and most arguments are moves.
 
-### Follow-ups (non-trivial, revisit before building the elision)
-
-- **The liveness is a first cut.** The loop rule is sound but coarse. A full version wants proper
-  dataflow liveness: nested loops, `break`/`continue`, conditionals and merge points, multiple
-  reaching definitions, and cross-block moves. The current rule is intentionally conservative, so it
-  under-counts rather than ever over-counting, but the real elision transform needs the stronger
-  analysis to catch the cases it currently rejects.
-- **Find more elision categories.** Beyond the three movable categories there are more: a value
-  returned moves ownership out of the function (its drop is elidable), a uniquely-owned orphan
-  temporary's drop can become a direct free rather than a decrement-and-check, a retain and release
-  that cancel within a block regardless of category, and a struct construction that moves its fields
-  in rather than retaining them. Each is its own rule to measure and prove.
-- **The counts are static, not runtime-weighted.** They count retain sites in the code, not their
-  execution frequency, so they show the shape of the opportunity rather than the exact runtime total.
-  Weighting by the per-request hot path would bridge to the runtime `vm-counters` number.
-- **Then build the transform.** The mechanism is already present: the dormant `moved` flag, which the
-  drop emitter already respects. The elision sets it for proven moves and skips the paired retain,
-  keyed on the same decision the measurement makes.
+### The elision transform (built, conservative first cut)
+
+`elidable_moves` in the lowering decides when a reference-typed variable's last use moves it into a
+consumer (a call argument, a spawn argument, or an aliasing copy), and the lowering skips both the
+retain at that site and the variable's drop. It is deliberately conservative, so it can only
+under-elide, never over-elide: the site must be the last real use (loop-aware), the variable must
+appear exactly once at the site, and it must have a single drop the move dominates (approximated by no
+control flow between the move and the drop). Measured on the http hello path: incref 102 to 81 and
+decref 172 to 151 per request, memory-safe, all suites green.
+
+### Refinements (there is a lot of headroom)
+
+The static analysis found 80 movable retains but the runtime elided about 21 per request, so the gap
+is the conservatism plus what actually runs on the hot path. Each refinement widens what is elided, so
+each needs its own review since that is where an unsound over-elision would hide.
+
+- **Proper dominance instead of "no control flow between".** The current straight-line rule rejects a
+  move that happens before a branch, or in a `match` arm, even when the move still dominates the drop.
+  A dominance analysis catches those and enables per-path and multi-drop elision.
+- **Full dataflow liveness.** Nested loops, `break`/`continue`, merge points, and multiple reaching
+  definitions, replacing the loop-and-linear-last-use approximation.
+- **More elision categories.** A value returned moves ownership out of the function, so its drop is
+  elidable. A uniquely-owned orphan temporary's drop can become a direct free rather than a
+  decrement-and-check, which attacks the roughly 94 allocations per request that RC-op elision alone
+  does not touch. A retain and release that cancel within a block regardless of category. A struct or
+  enum construction that moves its fields in rather than retaining them.
+- **The report counts are static, not runtime-weighted.** Weighting by the per-request hot path would
+  bridge `--rc-report` to the runtime `vm-counters` number.
+
+### Guiding model: Rust's analysis as an oracle, not a gate
+
+The north star is to take Rust's ownership and borrow analysis as an internal optimization oracle
+while keeping none of its surface. Where the analysis proves a value's lifetime is clean the reference
+counting is dropped, and where it cannot the reference counting stays, which is always correct. So the
+programmer never sees a move, a borrow, or an ownership error, and no program is ever rejected. This
+is the difference from Rust: Rust rejects what it cannot prove, this keeps the refcount.
+
+Under this model the current move elision is only the caller-side, last-use case. The larger lever is
+the borrow, Rust's `&T`: a parameter the callee only reads is borrowed, so the caller needs no retain
+at all, even when it uses the value again after the call. Realizing it needs a per-function escape
+summary (does a parameter get stored into a field, returned, or spawned, or is it only read), which
+makes it interprocedural and wants a fixpoint over recursion. It stays fallback-safe: an unknown or
+conservatively-escaping callee just keeps the retain, so a wrong summary costs performance, never
+correctness. Most parameters are borrows, so this is a much larger category than move elision, and
+together they approach a common case with no reference counting, leaving it only for genuine shared
+references, escapes into aggregates, and cycles, where the future cycle collector takes over.
 
 ## Where this sits