Gmail Workspace add-on for phish reporting

[jusso-dev]

Why

The Outlook M365 add-in (issue #6) is shipping in the first half of integrations work. Gmail Workspace customers need feature parity — a one-click "Report phish" button inside Gmail on the web and mobile that POSTs the message body, headers, and attachment metadata to /api/addin/report.

Without this, Workspace customers either rely on the forward-to-mailbox path (worse UX, easier to forget) or use a competitor product. PAB-style buttons inside the mail client are now table-stakes for security awareness platforms.

Scope

• Apps Script project under public/addins/gmail/ (or a sibling repo if Workspace tooling demands it).
• appsscript.json manifest with gmail.contextualTriggers so the "Report" card surfaces when an email is open.
• Card builder UI: subject preview + "Report email" button + confirmation state.
• POST to the existing /api/addin/report endpoint with the same payload shape as Outlook (subject, fromAddress, headersRaw, bodyText, bodyHtml, attachmentsMeta, reporterEmail, messageId, source: "gmail").
• Settings → Integrations: add-on install URL/instructions for Workspace admins.
• Reuse extractToken / token-vs-real-mail differentiation already implemented in the Outlook PR.

Acceptance

• Add-on installable from the Workspace Marketplace (or via private manifest deployment for the staging tenant).
• Reporting a simulation marks reportedAt + emits reported event (already covered by the ingest endpoint when token matches).
• Reporting a real mail creates a real_mail_report row.
• Settings page shows the install URL + Workspace admin instructions.
• Documented in README.md integrations section.

Notes

• Follow-up to Outlook + Gmail + Teams phish-report add-in #6. The shared /api/addin/report endpoint and real_mail_reports table are already live, so this PR is scoped to the Apps Script add-on + docs.
• Apps Script's UrlFetchApp does not have the same CORS constraints as a browser fetch — verify auth posture before relying on Bearer tokens.