spec(opera-safari): Opera Add-ons and Safari Web Extension distribution scoping (no implementation)

[Kotmin]

Context

Scoping issue, not an implementation issue — same convention as #6: no PR
against any item here without K's explicit sign-off. Filed per K's direction
(2026-08-06) as the follow-up to #6's own suggestion that Opera and Safari
be tracked "as separate ones" once Chrome/Edge CI landed. Goal: gather enough
specification that follow-up work can be scoped into atomic PRs, same as #6
did for Chrome/Edge.

What's already true (confirmed by code inspection, no action needed)

• Shared-source layout (ADR-0008) already separates checked-in files
  (manifest.json, README.md) per edition from generated files
  (src/, assets/, lib/), materialized by scripts/sync-extension-lib.sh.
  Adding a new edition dir is a small, well-worn move (c6abda8 added
  chrome+edge this way).
• scripts/check.sh already enforces MV3 + manifest-field parity across
  every dir under apps/ it's told to check — extending the APPS list is
  one line, not a redesign.
• Firefox → Chrome → Edge CI pipelines (release-firefox.yml,
  release-chrome.yml, release-edge.yml) now give three worked examples of
  "check → test → package → changelog → store-submit → GitHub release" to
  follow or deliberately diverge from.

Opera — open questions

• Opera is Chromium/Blink-based (MV3-compatible), so the packaged zip is
  likely reusable as-is or near-as-is, the same way Edge currently ships
  byte-identical to Chrome (ADR-0008).
• Distribution goes through Opera Add-ons (addons.opera.com), a separate
  store from CWS — Opera does not auto-mirror a Chrome Web Store listing.
• Unconfirmed, needs research before any implementation (same
  verify-before-code approach used for docs/release/cws-api-contract-findings.md
  and docs/release/edge-api-contract-findings.md): does Opera Add-ons expose
  any programmatic submission API at all, or is first-and-every submission
  manual through the web UI? If there's no API, CI can only package+lint, not
  publish — that changes the shape of release-opera.yml substantially (no
  secrets, no publish step, just an artifact + a manual-upload reminder).
• Open question: pursue Opera at all, given it's a smaller install base than
  Firefox/Chrome/Edge — K go/no-go, not a technical question.

Safari — open questions

• Safari extensions are not a zip-upload flow at all. Apple requires
  converting a web extension into a Safari Web Extension via Xcode's
  safari-web-extension-converter, wrapped in a macOS/iOS app shell, then
  distributed through the Mac App Store (or notarized outside it) using
  Xcode/Transporter and an Apple Developer Program membership ($99/yr).
• This means: a macOS build agent (GitHub Actions macos-latest runner, not
  the ubuntu-latest every other pipeline here uses), Apple signing
  certificates/provisioning profiles as CI secrets, and an Xcode project
  checked into (or generated into) the repo — a materially bigger lift than
  Chrome/Edge/Opera, not a same-shape addition.
• Unconfirmed: whether Manifest V3 core (src/, apps/shared/) is portable
  enough as-is, or whether Safari's WebExtensions API gaps force adapter
  changes before packaging is even possible. Needs a research pass before
  any ADR, let alone implementation.
• Open question: given the cost (paid developer account, macOS-only CI,
  Xcode project maintenance), is Safari in scope at all for a project this
  size, or does it stay permanently out of scope — K go/no-go.

Non-goals for this issue

• No pull requests / code changes without K's explicit sign-off per item.
• No Opera/Apple developer account creation — blocked on K's identity/
  ownership decision, same as spec(chrome-edge): Chrome/Edge Web Store parity, domain-separation guard, and PRD Milestone 9-10 scoping (no implementation) #6's Google/Microsoft accounts were.
• No commitment that either browser ships — this issue exists to gather
  enough information for K to make that call, not to pre-decide it.

Next step

K to answer, per browser: (a) go/no-go on pursuing it at all, (b) who owns
the developer account if go. Once answered, the research-then-implement
pattern from Edge (contract-findings doc → developer-setup doc → bootstrap
workflow → release workflow) is the template to follow.

Relates to #6 (Chrome/Edge scoping — the issue this one continues from).