Clarify browser support and repair shared candidate qualification

[sarthakagrawal927]

The signed app’s support wording advertised Brave/Chromium-family support while tab Automation targets Chrome. Candidate CI also stopped before testing because its shared tooling pin expected the retired repository owner. This aligns the two support strings with the current supported browser policy and pins candidate CI to the reviewed producer that accepts Significant-Hobbies/browserdaddy.

The consumer now includes the exact canonical appcast_core.py and integrates it into the app-owned preparation wrapper. The wrapper preserves BrowserDaddy’s signing account, protected-key handling, update URL, codesign verification and stapler validation, while rejecting ambiguous checksums, invalid artifacts, mismatched enclosure URL/length/signature metadata and staged-byte drift. The release workflow and native permissions retain their existing configuration.

Validation at source head c24b1f8333d36c179a6ba3695629d4ce69570f3a:

• Six consumer Sparkle tests pass, including 26 actual-wrapper fixture scenarios with synthetic artifacts and mocked external tools; six Worker tests pass.
• Canonical repository attribution and all three shared helper byte checks pass against producer de31581b56fa8b6c20a03d0846ad2204aa2c9bab; producer contract and shared appcast fixture suites pass.
• Both approved Swift copy fixes remain byte-identical. Diff checks pass. Exact-head GitHub CI passed both the native test job and shared candidate job.

These fixtures qualify source behavior and signature metadata shape. Cryptographic verification, installed update behavior, broader browser Automation and background routing acceptance remain separate open work.

Related: #23, #25, sass-maker/saas-maker#151. This draft does not close those issues.