F8.2c: Register PWA file handlers and consume OS launches

[Flow-Fly]

Parent

• F8.2 — OS file-handler registration for .pf / .aseprite #123

Goal

Let the installed desktop PWA receive user-opened .pf, .ase, and .aseprite files and route them through the shared import service.

Context

Chromium owns the permission prompt and supplies only files the user explicitly opens. Pixel Forge will feature-detect the API, store no file handles, and read files only for the current launch.

Risk and routing

Risk: low
Readiness: ready-for-agent

The capability is declarative, read-only, browser-mediated, and progressively enhanced. Firefox and Safari behavior remains unchanged.

Acceptance Criteria

• The production manifest declares Pixel Forge and Aseprite file handlers with relative in-scope actions.
• Launch handling focuses the existing installed app and delivers multiple files to one client.
• A launch-queue consumer imports every supplied supported file through the shared service.
• Unsupported browsers start without warnings or errors.
• File handles are not retained and no write permission is requested.
• Generated-manifest and mocked launch-queue behavior are tested.

Suggested Files

• vite.config.ts
• src/main.ts
• src/services/pwa-file-handling.ts
• a narrow DOM type declaration
• focused tests

Verification

• Focused Vitest launch-queue tests.
• Inspect dist/manifest.webmanifest after build.
• npm run test:run
• npm run build
• git diff --check

Dependencies

• Uses the shared project import service and context-aware Aseprite import from the preceding child issues.

Out of Scope

• Persisting file handles.
• Saving back to the source file.
• Mobile file association.

[Flow-Fly]

Agent Assessment

Risk: low
Agent-ready: yes
Routing: ready-for-agent

Evidence:

• Chromium owns file-handler permission and supplies only user-opened read handles.
• The implementation is feature-detected, retains no handles, requests no write permission, and uses the tested import service.

Why this is safe:

• Declarative manifest metadata plus a narrow progressive-enhancement adapter; unsupported browsers are untouched.

Verification:

• Mocked launch-queue tests, generated-manifest inspection, full tests, production build, and diff check.

Human question or blocker:

• None for implementation. OS association remains a final playtest check.

[Flow-Fly]

Implemented in #334 (commit 169b8e9). Manifest generation and mocked launch-queue behavior are covered. Awaiting the parent installed-PWA playtest and merge gate.