Validator parity: browser and CLI must agree

[itsbdell]

Problem

The reference CLI (appfeed) uses ajv with the canonical
spec/apps.schema.json. The browser reader (site/validator.js) is
a hand-rolled validator that re-encodes the same constraints in JS.

These two implementations can drift. The hard contract today (version
required, apps[] required, per-app name + url required) is
covered in both, but every future schema change risks subtle
divergence: a field accepted by the CLI but rejected by the reader,
or vice versa.

This is a P1 because the spec's promise — "any validator should agree
on what's valid" — is the credibility anchor of the standard.

Acceptance criteria

• A single source of truth drives both validators, OR
• Both validators run against a shared corpus of fixtures (valid +
  invalid) in CI and any disagreement fails the build.

Options

1. Replace hand-rolled with ajv-bundled-for-browser. Ship a built
   ajv bundle to site/. Adds ~50KB but eliminates drift by
   construction.
2. Shared fixture suite. Keep both implementations but add a
   test/fixtures/parity/ corpus and a CI job that runs each fixture
   through both validators and asserts identical
   { ok, errorPaths[] }.
3. Codegen the JS validator. Generate validator.js from the
   schema at build time (e.g. ajv-standalone). Bigger investment.

Recommended: start with (2), revisit (1) when the schema gets richer.

Notes

Surfaced by 5 of 11 reviewers in the v0.1 code review. Tracking issue
linked from appfeed/README.md and site/validator.js once a
direction is picked.