Rewrite UX: one call for all bullets vs per-bullet trigger

[s-annam]

Context

PR #49 flattened per-bullet feedback and made the WebLLM "Rewrite" affordance a slim inline link on each failing bullet. That's a clear improvement over a bordered button per row, but it still surfaces one rewrite trigger per failing bullet (13 on a typical resume).

Question to settle

Is per-bullet, on-demand rewrite the right model — or should there be a single action that rewrites all flagged bullets at once (one model load, batched inference, results shown inline per bullet)?

Considerations

• Model load cost: the ~1.2 GB Qwen2-1.5B download is the dominant cost and is one-time/cached. A single "Rewrite all" amortizes the first-load wait across every bullet instead of paying the perceived cold-start on the first individual click.
• Repeated-action anti-pattern: a per-row trigger × N rows is the "repeated actions per row" smell. A single batched action (with per-bullet results) sidesteps it.
• Control: per-bullet keeps the user in control of which bullets to spend inference on; "rewrite all" is faster but less surgical. A hybrid is possible — "Rewrite all flagged" primary + per-bullet re-roll.
• WebGPU-only / failing-bullet-only scoping stays the same regardless of trigger model.

Scope

• Decide the interaction model (single / per-bullet / hybrid).
• If batched: progress UI for N bullets, partial-failure handling, and where results render.
• Keep the lazy 1.2 GB load on explicit action only (never on mount).

Follow-up to #39 (rewrite pilot) and #49 (flatten + inline affordance).

[s-annam]

Superseded by #63 (Phase 1 of epic #66). The one-call-vs-per-bullet question is decided: replace whole block — model owns bullet count/order, section-level accept/reject. Implementation tracked in #63. Kept as a sub-issue of #66 for history.