feat: allow browser extension origins in auth requests

[apirJS]

feat: allow browser extension origins in auth requests

Problem

Browser extensions sending requests to /auth/get-user-app-token with their native origin (e.g. chrome-extension://cafneielldmiliebnkhaeaaibinihgpb) receive a 400:

{
  "error": "Invalid origin URL",
  "message": "Invalid origin URL",
  "code": "bad_request"
}

This happens because AuthService.#originFromUrl only accepted http: and https: protocols. Browser extensions are legitimate OAuth-style clients and should be able to obtain app tokens the same way web origins do.

Changes

Extend the protocol allow-list from ['http:', 'https:'] to include browser extension schemes:

Scheme	Browser
chrome-extension:	Chrome / Chromium
moz-extension:	Firefox
safari-extension:	Safari App Extensions (legacy)
safari-web-extension:	Safari Web Extensions (modern)
extension:	Generic / Chromium forks

The allow-list is used in three places - all three are updated consistently:

• AuthService.#originFromUrl - gatekeeps appUidFromOrigin(), which is the entry point that returned the error
• AppStore.createFromOrigin - validates origin before persisting it as index_url on bootstrap app rows
• AppDriver.#validateInput - validates index_url on developer-created/updated app rows

DRY extraction

The protocol array was duplicated across all three files. This PR extracts it into a single exported constant:

// src/backend/util/validation.js
export const WEB_AND_EXTENSION_PROTOCOLS = [
    'http:', 'https:',
    'chrome-extension:', 'moz-extension:',
    'safari-extension:', 'safari-web-extension:',
    'extension:',
];

All three consumers now import and reference this constant.

Security

• No weakening of existing constraints. Dangerous schemes (javascript:, data:, file:, vbscript:) remain rejected - the existing negative tests confirm this.
• hostname guard. AuthService.#originFromUrl checks parsed.hostname is non-empty after the protocol check. All extension schemes produce a hostname (the extension ID), so this passes correctly while still blocking edge-case schemes that parse without a host.
• Opaque origins. Browser extension schemes produce opaque origins per the WHATWG URL spec - they cannot read cookies, storage, or DOM from the parent frame when loaded in an iframe. An extension's ID is cryptographically tied to its signing key (Chrome/Firefox) or developer account (Safari), so the origin is not user-injectable.

How existing callers are unaffected

• http: and https: origins work identically - the allow-list is a strict superset.
• No changes to response shapes, error codes, or token format.
• The validateUrl utility's default protocols parameter (['http:', 'https:']) is unchanged; only callers that explicitly pass the extended list are affected.

Tests

Layer	File	What's tested
Service	AuthService.test.ts	appUidFromOrigin resolves 5 extension origins to deterministic app UIDs
Store	AppStore.test.js	createFromOrigin accepts a chrome-extension:// origin and persists it
Controller	AuthController.test.ts	handleGetUserAppToken end-to-end with an extension origin -> token + bootstrap row

[CLAassistant]

All committers have signed the CLA.

[Salazareo]

looks sane, just reviewing now