Remove activeTab from the Chrome package: redundant next to host permissions #61

Per the convention that permission-surface changes get a public Issue (CONTRIBUTING.md), and ahead of the v1.0 permission freeze and Chrome Web Store submission.

Analysis

The manifest requests activeTab alongside host_permissions for http://*/* and https://*/*. With broad host permissions present, activeTab grants nothing the extension does not already have. Chrome's restricted "on click" site-access mode is implemented by the browser withholding and re-granting host permissions on invocation, and does not depend on the activeTab permission. The Chrome Web Store requires the narrowest permission set that supports shipped functionality; a redundant entry works against review and against the store listing's permission-justification fields.

Change (targeting 0.11.0)

scripts/package-chrome.sh now strips activeTab from the staged manifest when building the Chrome zip, so the submitted Chrome package ships with storage, scripting, cookies, and host permissions only. This is the single point where the shipped Chrome manifest diverges from the repository manifest.

The repository manifest (which the Safari build mirrors) keeps activeTab for now. The previous permission-narrowing experiment broke Safari detection in unpredicted ways, so Safari-side removal is deliberately deferred to the Safari / App Store store-readiness pass, where it must be re-evaluated and tested before that submission. Until then, Safari intentionally ships the superset.

Verification

• Chrome: load the packaged (trimmed) build, confirm detection, popup probe, and clear-site-data work
• Chrome: set site access to "when you click the extension" and confirm on-click behavior still works without activeTab
• Safari (deferred to Safari store-readiness): build with activeTab removed from the shared manifest and re-run the same checks before the App Store submission

Rationale documented in SECURITY.md's permissions section.