Extend #372's OS-authenticated approval to the SMTP send review: mail.review_send on Linux/Windows #481

Current state

mail.review_send and mail.send refuse on Linux and Windows with "Physical Mail send approval is unavailable on this platform" (apps/mail/host-service/src/public_review.rs:196-198 @ main 5c28da7d), and API discovery declares both methods for macos/android only (public_review.rs:260). docs/host-os-api-status.md records the same: send review is implemented on macOS/Android; Linux/Windows can compose/read status but have no physical-send adapter.

Since #409 / SDK 1.10 (4ccf8e06), the foreground native review is the only send path offered to store apps. On Linux/Windows a third-party mail app can sign in, read, compose drafts and read status, but cannot complete one end-to-end send; the honest positioning degrades to "read + AI + drafts" (e.g. the contest submission vibemail, which has to classify this refusal in its review-send callback).

Proposal

#372 adds an OS-authenticated native approval path on Linux and Windows — an exact root-owned polkit auth_self policy on Linux, owner-window Windows Hello accepting only native Verified on Windows — for Gmail, GitHub, Calendar and declared-backend native review. That mechanism gives Linux/Windows exactly what the SMTP send review lacks today: a trusted, non-synthetic physical authorization source.

This issue tracks extending it to the mail send review:

• Mount the existing native review sheet on Linux/Windows; the shell's connected_review::smtp_sheet path is not platform-gated, so the gap is the service-side refusal and the missing trusted approval source.
• On those platforms, authorize the opaque single-use Review capability with the Add OS-authenticated native write approval on Linux and Windows #372 OS-authenticated proof (polkit / Windows Hello) in place of the pointer-trusted Approve & Send control, preserving the immutable-revision, single-attempt and foreground-only guarantees.
• List mail.review_send/mail.send for linux/windows in API discovery only once each platform actually has its adapter.
• Keep synthetic input untrusted, as Add OS-authenticated native write approval on Linux and Windows #372 does.

Acceptance

• Refusal-without-authorization and expired-proof paths tested for both platforms, mirroring Add OS-authenticated native write approval on Linux and Windows #372's negative-path receipts.
• Real SMTP acceptance on hardware remains its own unverified item, as it is today.

Notes

I maintain a Windows store mail app that currently has to report this as a platform limitation; happy to test a Windows build once an adapter lands.