[Frontend][UX] Paper Inbox: port pre-triage capture edit from the Legacy detail panel

[Chris0Jeky]

Split out of #1944 (AC 2). The other four ACs of #1944 ship in its PR; this one is a
Paper-skin porting gap, not a small addition, so it is tracked separately rather than
gold-plated onto a feedback fix.

Why it is a porting gap, not backend work

• The API already exists: PUT /api/capture/items/{id}/suggestion
  (backend/src/Taskdeck.Api/Controllers/CaptureController.cs, HttpPut("{id:guid}/suggestion")),
  fronted by captureApi.updateSuggestion in frontend/taskdeck-web/src/api/captureApi.ts.
• The Legacy skin already has the affordance: frontend/taskdeck-web/src/components/inbox/InboxDetailPanel.vue
  renders an Edit Text button (data-testid="suggestion-edit-btn") and a textarea placeholder
  "Edit the capture text before triage...", both gated on selectedItem.canEditSuggestion === true.
• The Paper skin has no detail surface at all to hang it on: PaperInboxView.onTriageOpen() is a
  documented no-op, and the triage row only holds textExcerpt, not rawText.

So the work is: a Paper editing surface (inline row editor or a Paper detail drawer), a detail fetch
to get rawText + canEditSuggestion, save/cancel wiring to updateSuggestion, the
canEditSuggestion === false explanation, and specs. That is a design decision plus a feature, which
is why it is not folded into the #1944 feedback fix.

Acceptance criteria

• A capture's text can be edited in the Paper Inbox before triage, preserving provenance rules
  (server-stamped provenance, no client identity fields).
• A capture that cannot be edited (canEditSuggestion !== true) says so instead of offering a
  dead affordance — same rule as [Frontend][UX] Capture triage: no pre-triage edit, and Accept/Reject give no legible state feedback #1944/[Frontend][Testing] Guard against dead affordances - six enabled-but-inert controls found in one audit pass #1949: never enabled-and-silent.
• Specs cover the editable path, the save failure path, and the not-editable path.