feat(composer): compose spoiler, annotation, and tooltip controls

[tellaho]

Category: improvement
User Impact: Users can mark text and individual image/video attachments as spoilers independently, annotate uploaded images, and get composer tooltips that dismiss correctly from the final combined composer UI.

Problem: The composer’s previous spoiler model coupled text spoilering to pending media, so marking text as spoiler could also hide every attached image/video. In parallel, uploaded-image annotation and tooltip-dismissal fixes touched the same composer attachment/lightbox surfaces, making the intended combined behavior easy to lose during conflict resolution.

Solution: This PR is now the collapsed composer stack for #1491 + #1488 + #1272. It keeps text spoiler as a text-only formatting action, moves media spoiler control into each attachment’s annotation-capable lightbox, preserves uploaded-image draw/save/revert behavior, and applies tooltip dismissal to the controls that survive in the final combined UI.

Final composed behavior

• Text spoiler stays text-only in the formatting toolbar.
• Media spoiler is per attachment from the lightbox action bar.
• Uploaded images use the annotation-capable MediaAttachmentItem path with view/edit modes.
• The spoiler toggle is hidden while editing/drawing so the image remains unblurred for annotation.
• Tooltip dismissal applies across the final composer controls: remove, revert, spoiler, edit, attach, mention, emoji, text-spoiler, and formatting toggles.
• SimpleImageLightbox was extended additively with optional actions; existing consumers such as ViewImageToolPreview are unchanged.

Stack / merge history

This branch intentionally carries the combined composer stack so the merge order is traceable in GitHub history instead of relying on code comments:

1. feat(composer): compose spoiler, annotation, and tooltip controls #1491 — split text vs. per-media spoiler semantics.
2. feat(uploads) add image annotation tools to composer uploads #1488 — merged into this branch; annotation remains the media path, with the per-attachment spoiler toggle hosted in the annotation lightbox.
3. fix(composer): dismiss composer tooltips when cursor leaves the trigger #1272 — merged into this branch; tooltip dismissal is applied to the final composed UI.

#1487 and #1490 stayed independent solo PRs against main.

Validation

• biome check ✅
• tsc ✅
• unit tests ✅
• build ✅
• cargo check ✅
• e2e: spoiler + composer-tooltip-dismiss + composer-image-draw ✅

Screenshots

Lightbox view-mode action bar with spoiler / draw / close:

Composer thumbnail after per-attachment spoiler:

Notes

• The old bulk text-to-media spoiler path is removed; tests now assert the decoupled behavior directly.
• The previous overlap notes for feat(uploads) add image annotation tools to composer uploads #1488/fix(composer): dismiss composer tooltips when cursor leaves the trigger #1272 are resolved by this collapsed stack.

[tellaho]

CI note, corrected after rebase: Desktop Smoke E2E had repeatedly failed the same pre-existing scroll-history assertion by half a pixel (observed 28.5px vs allowed 28px) after several rekicks, while spoiler-specific checks stayed green. Latest main now carries the scroll tolerance fix (32px with rationale), so after rebasing this PR no longer includes an unrelated scroll-test diff.

[wesbillman]

Reviewed the full diff (18 files, +1406/−274) as the collapsed #1491 + #1488 + #1272 stack. Traced the upload/cancel accounting in useMediaUpload, the new Rust IPC command's validation path, and the lightbox key/remount trick. The architecture is sound and the sharp edges are handled well:

• uploadEditedAttachment / revertAttachment preview-count and finishUpload bookkeeping balances on success, cancel, and error paths (cancel and onUploadError each own their decrement — verified against cancelUpload).
• Keying MediaAttachmentItem by originalUrl ?? attachment.url is a neat trick: edit-save and revert both preserve the key, so the open dialog never remounts. Correct in both directions.
• fetch_media_bytes reuses the exact SSRF/origin/size-cap/MIME validation as the download commands — no new attack surface beyond the existing envelope.
• Spoiler-membership migration across URL swaps (useAttachmentEditing) is small and covered by the e2e spec.
• The pruning effect on pendingImeta and the same-callback batched slot-swap + originals re-key are consistent (React batches both setters), so revert state can't observe a torn intermediate.

Findings, none blocking:

1. Dead code: SimpleImageLightbox's new actions prop has no consumer. After the collapse, ComposerAttachments builds its own DialogPrimitive-based lightbox, and the only remaining SimpleImageLightbox consumer (ViewImageToolPreview) doesn't pass actions. The PR body still describes this as an additive extension for the composer, but the final composed code never uses it — suggest reverting SimpleImageLightbox.tsx to main unless a follow-up needs it.

2. Perf nit: fetch_media_bytes returns Vec<u8> as a JSON number array over IPC. With the 50 MiB cap that's a worst-case ~150 MB JSON payload to deserialize into number[]. tauri::ipc::Response would send raw bytes. Fine to ship as-is for typical image sizes; worth a follow-up if large images feel slow to enter edit mode.

3. UX nit: Escape during save exits edit mode but doesn't abort the in-flight upload — the save still completes and swaps the attachment after the user apparently backed out. Low stakes (the swap is revertable), just noting it's a known race.

4. Revert affordance is lost across a draft/channel round-trip — the originals map is in-memory and pruned when the attachment leaves pendingImeta. The code comment documents this as intentional; agreed it's the right scope, flagging only so it's a recorded decision.

5. Several of the new comment blocks (e.g. the 8-line tooltip rationale in MessageComposerToolbar, the multi-line lightbox-close rationale) restate design justification that lives in the PR body. House style here trends much leaner — consider trimming to one line each.

CI: all 26 checks green, including both Desktop E2E Integration shards which run the three new/updated specs. Approving — #1 is the only change I'd actually like to see before merge, and it's a deletion.