feat(#44): show a reduction % on every folded block and group

[a-Fig]

Closes #44.

What

Adds a small, on-brand reduction-percentage tag to every folded block and folded (collapsed) group so users can read how aggressive each fold was — light or heavy. Shows % of tokens REMOVED (saved / full × 100, rounded to a whole percent), consistent with the existing Map-header "saves X tok" copy.

Brand & taste (read brand/accordion-brand-kit/brand.md first)

• Smoke mono only — --muted (#9A9A9A, the brand "labels, metadata, fold states" color) on IBM Plex Mono. Never a spectrum hue, never blue (blue is reserved for user blocks), never on a live tile. The tag keeps the folded tile's recessed, drained calm (the ci: cross-platform release workflow (Tauri installers) #1 brand signal) — information, not decoration.
• Folded = recessed; the % is faint and inset.
• No hype words ("powerful," "seamless," …).

Three surfaces

surface	what
Pure helper engine/tokens.ts	reductionPct(full, live) — divide-by-zero → 0; unit-tested
Map canvas ui/map/tileDraw.ts	reductionPct? on TileSpec; cached offscreen sprite per rounded-5% value (≤21) blitted with drawImage — no per-tile fillText, no filter/gradient (CLAUDE.md perf rule). Drawn last, inset at tile bottom
Map specs ui/map/ContextMap.svelte	compute reductionPct in buildTilesSpecs + protSpecs (folded blocks + collapsed groups)
Sliver mode ContextMap.svelte	.cell-pct Smoke-mono badge on summary tiles (ungrouped fold + group cocoa + peeked open-band parent)
Transcript ContextMap.svelte	−N% (.tr-reduction) on folded cards
Tooltips ContextMap.svelte	tip/groupTip/foldTip include −N%
Inspector Inspector.svelte	−N% in the token data row for folded blocks and folded groups (.tok-reduction)

Data (pure reads, no wire change)

• Folded block: reductionPct(b.tokens, store.effTokens(b)).
• Folded group: reductionPct(store.groupFullTokens(g), store.groupLiveTokens(g)). A drop group → live 0 → 100%, signalling "the agent does not see this block".
• Zero-token block → 0 → no tag rendered.

Design calls left to the owner (made restrained defaults; flagged in case the screenshot loop wants to change)

• The dense Map canvas tile shows a bare number (e.g. 85), not −85% — a ~20px tile can't legibly fit 4 chars. The Transcript/Inspector/tooltips carry the full −N% form, which establishes the number's meaning. A different glyph is a one-line sprite change.
• Map-canvas precision is rounded to nearest 5% (sprite-cache bound); Inspector/Transcript show the exact whole-percent.

Verification

• cd app && npm run check → 0 errors / 0 warnings
• cd app && npm run test → 41 files, 809 tests passed (incl. new tokens.test.ts + 2 tileDraw.test.ts TileSpec cases)
• Did not run npm run dev (port 1420 may be busy; UI is for the owner's screenshot review).

[a-Fig]

Thanks for the review — finding addressed in 071d672.

You're right: reductionPct(100, 150) returned -50, and the fold surfaces that emit the value unconditionally (tooltip, foldTip, sliver badge, transcript badge, Inspector token row) would render −-50%. Reached because conductor replace substitutions are arbitrary content and their length is counted as the effective token cost without a shrinkage check.

Fixed at the helper (one place, so every surface is correct by construction):

export function reductionPct(full: live: number): number {
  if (full <= 0) return 0;
  const pct = Math.round(((full - live) / full) * 100);
  return Math.max(0, Math.min(100, pct));  // clamp to documented [0, 100]
}

The defensive test now asserts exact bounds — reductionPct(100, 150) === 0 and reductionPct(100, 0) === 100 (covers drop groups), plus a negative-live case reductionPct(100, -5) === 100. This also aligns the helper with the TileSpec.reductionPct "0-100" doc.

I deliberately did not add reductionPct > 0 guards at each render surface in addition to the clamp — the clamp is the single source of truth, and redundant guards at call sites would invite drift (exactly the bug that just happened: the test's comment claimed "the caller renders no tag for ≤ 0" while several callers didn't). The Map canvas's existing spec.reductionPct > 0 guard stays (it's a draw-skip optimization, not a correctness gate).

Re-verified: npm run check 0/0, tokens.test.ts 11/11, full suite 810/810 pass.