Harden browser push receiver capability detection

[insane66613]

Summary

Follow-up hardening for #139.

This PR does not make Edge a full Join receiver. It tightens the capability check so the extension only reports full browser receiver support when both sides of the current legacy Chrome receiver path are actually available:

• chrome.instanceID.getToken for the registration token
• chrome.gcm.onMessage.addListener for incoming push delivery

This prevents partial Chromium environments from registering as Join receivers when they can expose part of the old API surface but cannot actually receive messages.

Changes

• Reconstructs serialized cross-context errors as real Error objects before throwing them.
• Routes non-service-worker chrome.instanceID.isAvailable() through the service worker capability check instead of relying on local/offscreen context availability.
• Requires both Instance ID and the GCM receive listener before reporting native browser cloud-push receiver capability.

Why this matters

Join's browser receiver path requires end-to-end support. A token alone is not enough: if chrome.gcm.onMessage cannot fire, the extension can register as a receiver and silently drop every incoming push.

This keeps Chrome behavior intact while forcing unsupported/partial environments into the existing send-only fallback.

Stacking note

This PR is stacked on top of #139. GitHub may show the broader #139 changes in this diff until #139 is merged. The new commit in this branch is:

• Harden Edge receiver capability detection

After #139 is merged, this branch can be rebased so the PR diff contains only the follow-up hardening commit.

Validation

• node --check cross_context.js passes locally.
• Repo has no package.json or CI test runner, so no configured automated validation was available.
• This has not yet been full QA-tested as a complete Edge receiver, because that is outside the intended scope of this PR.

Manual validation recommended:

1. Load unpacked in Chrome and confirm browser receiver registration and receiving still work.
2. Load unpacked in Edge and confirm unsupported receiver capability falls back cleanly to send-only without service-worker console errors.

[joaomgcd]

Hi. Thanks for the PR. To clarify, are these supposed to make the extension fully work with Edge? What did you test the AI code with exactly? Thanks!

[insane66613]

Thanks for asking. I updated the titles/bodies of #139 and this PR to clarify the scope.

No — these PRs are not meant to make Edge a complete Join receiver.

The current Join browser receive path depends on Chrome-only extension APIs (chrome.gcm / chrome.instanceID). My understanding is that Edge does not provide that same receive path, so complete Edge receive support would need a separate Web Push/FCM-style implementation and compatible server-side delivery support.

The intended scope is narrower:

• Improve Edge send-only compatibility handling #139 improves Edge compatibility handling and send-only fallback behavior.
• This PR hardens the capability check so the extension only reports full browser receive support when both chrome.instanceID.getToken and chrome.gcm.onMessage.addListener are present.

Testing performed:

• Static review of the changed cross-context and receive-registration paths.
• node --check cross_context.js locally.
• Repo AI review of the branch snapshot, which recommended this receiver-capability hardening.
• No package/CI test suite was available in this repo.

Not yet tested: full manual browser QA in a live Join account proving Chrome receive still works and Edge falls back cleanly to send-only. I added that limitation to the PR bodies so the scope is not overstated.

If you prefer, I can close this stacked PR and keep only #139 open until the broader Edge compatibility changes are reviewed first.

[insane66613]

Update: I ran a validation-focused Repo AI review and also did local smoke checks.

Repo AI validation result:

• Snapshot reviewed: fbc482cc, branch edge-receiver-capability-hardening.
• manifest.json parses as JSON.
• JavaScript syntax checks passed for the changed/relevant files, including cross_context.js, join.js, options.js, tests.js, service_worker.js, background_page_emulation.js, and v2/app.js as an ES module.
• Repo has no configured automated test suite, package script, or CI runner, so validation_count = 0.
• Receiver-capability logic was reviewed as correct: full browser receive capability is reported only when both chrome.instanceID.getToken and chrome.gcm.onMessage.addListener exist.
• Repo AI also confirmed this should not be represented as full Edge receiver support. It is send-only compatibility plus a hardened capability gate.

Additional local checks I ran outside Repo AI:

• git diff --check passed on the PR branch.
• manifest.json parsed successfully with PowerShell JSON parsing.
• node --check passed for background_page_emulation.js, cross_context.js, join.js, options.js, and tests.js.
• v2/app.js passed syntax check when parsed as an ES module.
• Chrome 149 unpacked-extension load smoke: launched with the PR branch and remote debugging exposed the Join service_worker.js target.
• Edge 150 unpacked-extension load smoke: launched with the PR branch and remote debugging exposed Join extension background/service-worker targets.

Still not tested:

• Live Join account end-to-end behavior.
• Chrome receiver regression with an actual incoming message.
• Edge send-only behavior in a real account.

So the accurate status is: static validation and local unpacked-extension load smoke passed; live account QA has not been done; this is not verified full Edge receiver support.