design-md-consolidation 1.5 fixup: untangle line 863 run-on, deduplicate JOURNAL attribution, idiomatic 'larger still'

docs/DESIGN.md

@@ -860,16 +860,18 @@ amortises against one allocation. The corpus was later extended
 with `bench_closure_chain` (closure-pair allocation: each step
 allocates *two* heap objects, the closure cell and its captured
 env struct) and `bench_hof_pipeline` (poly-ADT + indirect
-dispatch). The closure-chain fixture measures wider than the 1.3× linear/tree target — the doubled allocation tax on closure construction is reflected (current ratio recorded in JOURNAL bench entries) —
-each step pays two allocs and two decs against one bump-pointer
-bump. This is a representational cost of the closure-pair layout,
+dispatch). The closure-chain fixture measures wider than the 1.3×
+linear/tree target: each step pays two allocs and two decs against
+one bump-pointer bump, doubling the allocation tax on closure
+construction (current ratio recorded in JOURNAL bench entries).
+This is a representational cost of the closure-pair layout,
 not a defect in the RC implementation; a future slab/pool
 allocator for fixed-shape pair cells (Decision 9 retirement
 follow-up) would compress this ratio without changing semantics.
 
 The 1.3× retirement target therefore applies to the linear /
 tree / poly-ADT subset of the corpus. Closure-heavy workloads are
-tracked under a wider band (the closure-chain baseline records its rc/bump ratio as the `rc_over_bump` reference value with ±15% tolerance, recorded in JOURNAL bench entries) and
+tracked under a wider band (the closure-chain baseline records its rc/bump ratio as the `rc_over_bump` reference value with ±15% tolerance) and
 are explicitly excluded from the Boehm-retirement gate until a
 slab/pool answer ships. Decision-10's RC commitment is unchanged;
 what is scoped is the *quantitative* retirement criterion, not
@@ -1609,7 +1611,7 @@ The correct rationale is one level up: **mono makes the call target
 visible to the optimiser, unlocking inlining and downstream loop
 transformations that virtual dispatch prevents in principle.** The
 measured end-to-end win on a tight LCG hot loop is substantial vs
-non-inlinable direct call and larger again vs polymorphic vdisp (4 distinct
+non-inlinable direct call and larger still vs polymorphic vdisp (4 distinct
 targets cycling). On larger callee bodies or cold call sites the
 inlining win shrinks toward zero, but the architectural claim — "mono
 enables optimisations vdisp forbids" — holds across the spectrum,