Record the elision review verdicts and Bug 14

Both reviews passed: the soundness review proved residual balance per consumer
kind against the pre-elision build, and the adversarial review reproduced no
double-free, use-after-free, or elision-introduced leak across about 29 attack
programs with a finalizer oracle. Record the verdicts and the two plausible-only
approximation gaps (control_flow_between not treating Return or Call as control
flow, safe today, to be made explicit by the dominance refinement) in
RC_ELISION.md.

Record Bug 14, found pre-existing by the adversarial review: continue inside a
while skips the drops of references created earlier in the loop body, leaking
them on the continued path. The fix direction mirrors the early-return drop
handling.

Author: Axmouth

plans/KNOWN_BUGS.md

@@ -71,6 +71,17 @@ declared without a return-type annotation (its inferred return is indeterminate)
 loose typing the dedicated paths had, narrowed here rather than fully closed. Found by the arc 1a
 adversarial review, reconfirmed as the residual channel by the arc 1b and Bug 12 reviews.
 
+## Bug 14 (OPEN, moderate): `continue` skips drops of references created earlier in the loop body
+
+A `continue` inside a `while` jumps to the next iteration without releasing reference-typed values
+created earlier in that iteration's body, so each continued iteration leaks them (a finalizer-bearing
+resource created before the `continue` never runs its finalizer on the continued path). The normal
+fall-through end of the body drops them correctly, so this is drop placement on the `continue` jump
+path, the same family as the early-return drops that `emit_return_param_drops` handles for `return`.
+Pre-existing, found by the reference-count elision adversarial review by differential comparison
+against the pre-elision build (both leak identically, so the elision is unrelated). Fix direction:
+emit the current iteration's scope-end drops before the `continue` jump, mirroring the return path.
+
 ## Bug 13 (FIXED): a block match-arm in value position yielded the wrong value
 
 Three distinct issues surfaced together while prototyping a lisp interpreter. Their status differs:

plans/RC_ELISION.md

@@ -22,12 +22,24 @@ references), and a single drop the move dominates (approximated as no control fl
 drop). The `Drop` instruction itself stays in the IR, only its DecRef emission is skipped, so register
 lifetime bookkeeping is untouched.
 
-Measured on the http hello path: incref 102 to 81 and decref 172 to 151 per request. A soundness
-review traced the refcount balance per consumer kind against the pre-elision build (the residual
-`allocations + incref - decref` must match exactly) and found no imbalance anywhere, including the
-callee-returns-its-param and direct-finalizer cases. The invariant is caller-side pair cancellation:
-a matched retain and drop with the variable provably dead between them cancel regardless of what the
-consumer does.
+Measured on the http hello path: incref 102 to 81 and decref 172 to 151 per request. Two independent
+reviews confirmed soundness. The soundness review traced the refcount balance per consumer kind
+against the pre-elision build (the residual `allocations + incref - decref` must match exactly) and
+found no imbalance anywhere, including the callee-returns-its-param and direct-finalizer cases. The
+invariant is caller-side pair cancellation: a matched retain and drop with the variable provably dead
+between them cancel regardless of what the consumer does. The adversarial review ran about 29 attack
+programs (conditional moves, reassignment, spawn, loops with continue, match payloads, generics, a
+200-iteration stress with a printing finalizer as the oracle) differentially against the pre-elision
+build and reproduced no double-free, use-after-free, or elision-introduced leak. It also confirmed
+why the guards hold: single-drop plus no-control-flow-between put the move and its drop in one basic
+block, so the move trivially dominates the drop.
+
+Two review by-products are recorded elsewhere or below: a pre-existing `continue` drop-placement leak
+(KNOWN_BUGS Bug 14, identical on the pre-elision build), and two plausible-only approximation gaps.
+`control_flow_between` does not treat `Return` or `Call` as control flow. A `Return` between a move
+and the drop makes that drop dead code, and a `Call` returns to the next instruction, so neither was
+turnable into a fault, but the dominance-based refinement should make both explicit rather than
+incidental.
 
 ## The next lever: borrow elision (PLANNED)