Fix protected Firefox signing credential validation

[kbuffardi]

Summary

• Bind build-release-artifacts to the protected copilot environment.
• Keep AMO credentials step-scoped for validation and signing.
• Document the required environment and secret names.

Validation

• npm run lint
• npm run test:e2e
• git diff --check

Configure AMO_JWT_ISSUER and AMO_JWT_SECRET in the protected copilot environment before rerunning the release workflow.

Fixes #45

[kbuffardi]

Firefox validation investigation and fix plan

User request: "read comments on issue #46 for comments on failed Firefox validation. Plan a fix."

Findings

• PR Fix protected Firefox signing credential validation #46 has no top-level, inline-review, or review-submission comments.
• GitHub reports no checks for fix/firefox-unlisted-signing, so no failed Firefox validation log is available from this PR.
• The protected release workflow validates AMO_JWT_ISSUER and AMO_JWT_SECRET before dependency installation, then passes them to the unlisted XPI signing step. It declares the copilot GitHub Environment for that job.
• Therefore, the only evidenced failure mode is unavailable or empty AMO credentials in the environment that actually runs the protected release; this cannot be fixed by weakening signing or producing an unsigned artifact.

Plan

1. Repair protected configuration (owner action). Verify the copilot environment exists, is eligible for main pushes and workflow_dispatch, and contains non-empty environment or repository secrets named exactly AMO_JWT_ISSUER and AMO_JWT_SECRET. Do not expose their values to PR workflows or logs.
2. Reproduce in the real release path. Dispatch the protected release with force=true, approve the environment if required, and retain the preflight result plus any web-ext sign error. This distinguishes missing-secret validation from AMO credential/API failure.
3. If preflight still fails, align configuration and workflow. Make the job's declared environment match the environment where the secrets are stored (or move the secrets to copilot); retain the current step-scoped secret mappings and fail-closed signing gate.
4. Add regression coverage for the workflow contract only if step 3 changes YAML. Assert that the protected build job declares the intended environment, validates both secret names before npm ci, and supplies the same names only to the signing step. Keep the existing pure credential validation tests.
5. Verify completion. Run npm run lint, npm run test:e2e, and the relevant release workflow. Confirm a signed .xpi is recorded in the release manifest and uploaded; unsigned Firefox output remains a release blocker.

No code change is planned until a protected workflow run provides a concrete failure log.

[kbuffardi]

Follow-up: Firefox AMO validation artifact guard

Implemented the follow-up for issue #45 on this branch:

• Added a release-packaging regression test that opens the generated Firefox ZIP and verifies its root manifest.json contains background.scripts: [\"firefox-background.js\"], has no background.service_worker, and includes the Gecko add-on ID plus required data-collection permissions.
• Updated the release playbook to identify release/browser-cpp-firefox-v<version>.zip as the sole AMO upload candidate and require recording its filename, version, and SHA-256 from SHA256SUMS.
• Confirmed the generated browser-cpp-firefox-v0.3.zip contains the required Firefox manifest fields. SHA-256: e50b240701183dd4086a1402dd2a69e7b3a95cee3f19065e8bd0d1d141cdd807.

Verification completed:

• npm run lint
• npm run test:e2e (139 tests passed)
• npm run build
• npm run test:browser:firefox
• npm run package:release

AMO Developer Hub validation of this exact Firefox ZIP remains the external acceptance gate. The previously reported innerHTML warnings are not addressed by this manifest/artifact fix and should be investigated separately if AMO review requires it.