docs(spec,plan): giellie stock quantity update

The spec settles what was decided; the plan breaks it into 9 tasks
with the code each one needs.

Task order is the dependency order: the service learns to write a
negative quantity, a pure resolver learns to map a pasted line to a
stock item, a bulk service learns to apply and mirror, and only then
does the MCP tool, the agent prompt, the approval card, the composer
shortcut and the till tile hang off it.

Two corrections to the spec while writing the plan: the approval card
receives dotted MCP names, not model-facing ones, and the description
match takes the top candidate unless two are tied at the top - a bare
threshold would report 'ambiguous' for almost every description and
defeat the feature.

docs/superpowers/specs/2026-11-05-giellie-stock-quantity-update-design.md

@@ -172,7 +172,7 @@ The ledger note also stops claiming the edit came from `/stock`. The service cur
 
 `src/components/giellie/approval-card.tsx` currently renders `JSON.stringify(tu.input, null, 2)` for every tool. It gains a per-tool renderer: for `stock_items.set_quantities` it draws a table — Mode · SKU · Description · Qty — and every other tool keeps raw JSON exactly as today.
 
-The tool name arrives in the model-facing form (`stock_items__set_quantities`); the renderer matches on the unmangled name.
+The card receives dotted MCP names — `PendingToolUse.name` is documented as `orders.update`, not the model-facing `orders__update` — so the renderer matches on `stock_items.set_quantities` directly.
 
 The card renders the tool's **input**, because that is what the operator is approving — the mode, the SKUs and the quantities. The resolved before → after detail lives in the chat dry-run table shown a moment earlier, where unmatched and ambiguous lines are already visible. Between the two, the operator sees the plan and then the thing being committed.