Fix stale clipboard capture in macOS selection fallback

[fly1d]

Summary

• seed the clipboard with a private marker before the copy fallback
• wait up to 500 ms for a real clipboard change
• return a clear no-selection error instead of translating stale clipboard content
• preserve and restore the users existing clipboard as before
• add regression tests for marker, empty, and trimmed clipboard output

Risk

• Low: documentation, copy, styles, or isolated dictionary data
• Medium: UI behavior, translation provider, document parsing, or shared API
• High: selection capture, OS permissions, credentials, packaging, or releases

Verification

• npm run check
• npm run test:smoke when user-facing behavior changed
• npm run test:site
• npm run desktop:check
• rebuilt and launched the release app locally
• No API keys, user content, or sensitive logs were added
• Error and fallback states were exercised

Review Notes

A manual probe reproduced the old behavior: with copy unavailable, the fallback returned the previous clipboard value (✨) as selected text. After this change, the same probe returns 没有检测到选中的文字. The marker is generated from one Rust constant and is never exposed to the translation layer. Clipboard restoration runs on both success and AppleScript error paths.

[fly1d]

Reviewed the complete selection-capture diff at ab88aa5. The fallback now seeds the clipboard before issuing Copy, polls for a real change, restores the prior clipboard on both success and script errors, and maps an unchanged marker to an explicit no-selection error. The marker is sourced from one Rust constant, and regression tests cover marker, empty, and trimmed output. The original stale-content behavior was reproduced locally, the corrected failure state was exercised, a release app was rebuilt and launched, all local suites passed, and all five protected GitHub checks passed. No blocking findings.