Add native macOS sharing for aggregate usage cards

[Chipagosfinest]

Summary

Add a native macOS sharing action for aggregate usage cards so users can send the
same deterministic artifact through Mail, Messages, AirDrop, Notes, and other
installed sharing services.

This follows the local share-card work in #2112.

Current behavior

The preview exposes:

• Copy Image
• Copy Text
• Save

Users must manually switch applications and paste or attach the result.

Proposed contract

• Keep generation local and aggregate-only.
• Share the exact same immutable payload/image used by preview, copy, and save.
• Use the native macOS share surface (ShareLink/Transferable or
  NSSharingServicePicker) with a PNG file representation.
• Do not upload the card or create a public profile.
• Keep canonical public OG links as a separate, optional future decision.

Privacy requirements

The shared artifact must never contain account identity, API keys, prompts,
projects, file paths, or raw session events.

Acceptance evidence

• Native share opens from the share preview without blocking menu tracking.
• The shared file is a visible 1200×630 PNG.
• Mail/Messages-compatible file representation is covered by a stable seam test.
• Copy, save, and native share agree on payload and filename.
• make check and make test pass.

[Chipagosfinest]

Tracked in #2291. Follow-up PRs should link both this issue and #2291.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 23, 2026, 8:47 AM ET / 12:47 UTC.

Summary
Keep open: current main and the latest release still omit a native macOS share-sheet action, and this aligned new UI surface requires VISION.md sign-off before implementation.

Reproducibility: not applicable. this requests a new workflow, while current source confirms the existing preview only supports copy and save.

Ways to help us reproduce this

• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should CodexBar add a permanent native macOS share-picker action to the aggregate-card preview, limited to the existing on-demand sanitized PNG?	Approve local PNG sharing: Add a native share-picker action that exposes only the existing aggregate PNG generated on demand.

Why: VISION.md requires sign-off for this new user-facing sharing surface and its privacy boundary before code is promoted.

Next step
A maintainer must approve the new native sharing surface before a focused implementation is promoted.

Review details

Best possible solution:

Approve a privacy-local share picker that uses the same sanitized immutable PNG and filename as copy/save, with a focused seam test for the share item representation.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this requests a new workflow, while current source confirms the existing preview only supports copy and save.

Is this the best way to solve the issue?

Unclear pending product approval: reusing the existing sanitized PNG/export boundary is the narrowest maintainable implementation if the new surface is approved.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A native share service may consume its item asynchronously, so the implementation needs a stable on-demand PNG representation and explicit payload/filename parity coverage.

Codex review notes: model internal, reasoning high; reviewed against 4b14ed9c57d3.

Label changes

Label justifications:

• P3: This is a bounded optional sharing enhancement; users retain working copy and save workflows.
• impact:ux-friction: Users must currently switch applications and manually paste or attach the exported artifact to share it.

Evidence reviewed

What I checked:

• Current preview actions: The preview wires only Copy Image, Copy Stats, and Save actions; it has no native sharing action. (Sources/CodexBar/ShareStatsWindowController.swift:53, d6d281e898a0)
• Existing PNG contract: The exporter creates the 1200×630 PNG, writes it to the pasteboard, or saves it through NSSavePanel; this is the narrow seam a future share action should reuse. (Sources/CodexBar/ShareStatsRenderer.swift:37, d6d281e898a0)
• No current native-share implementation: The sharing subsystem has no ShareLink, NSSharingServicePicker, or Transferable use; the sole CoreTransferable result is unrelated menu-layout drag support. (Sources/CodexBar/ShareStatsWindowController.swift:1, 4b14ed9c57d3)
• Feature provenance: The original local usage-card feature was merged through the linked pull request, establishing the current preview/export boundary rather than native system sharing. (Sources/CodexBar/ShareStatsWindowController.swift:53, 7b11885ba51f)
• Release check: v0.54.1 resolves to d6d281e, and the two current sharing files are unchanged between that release and main; the omission affects both shipped and current-main behavior. (Sources/CodexBar/ShareStatsRenderer.swift:55, d6d281e898a0)
• Product policy: VISION.md identifies macOS as the UI home while requiring sign-off for new features and privacy-affecting behavior. (VISION.md:8, 4b14ed9c57d3)

Likely related people:

• steipete: Merged the original usage-card pull request and authored the current released snapshot containing the preview/export path. (role: merged feature owner and recent area contributor; confidence: high; commits: 7b11885ba51f, a97a220d4d96, d6d281e898a0; files: Sources/CodexBar/ShareStatsWindowController.swift, Sources/CodexBar/ShareStatsRenderer.swift)
• Alec Gutman: Authored the initial shareable usage-card commit in the feature history. (role: initial feature contributor; confidence: medium; commits: 39fa43b04bec; files: Sources/CodexBar/ShareStatsWindowController.swift, Sources/CodexBar/ShareStatsRenderer.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.