fix: a typo in flakemetry.yml must not stop the tests running

[AKogut]

Two defects found while auditing the platform against its promises rather than reading its code.

A config typo failed the build

flakemetry run -- <command> with an invalid flakemetry.yml and no FLAKEMETRY_ENDPOINT set:

exit: 1
stdout: []                                    ← the suite never ran
stderr: file:///…/contracts/dist/index.js:86  ← a stack trace, not a diagnosis

The wrapper exists so Flakemetry cannot fail a build. Not running the tests at all is the worst available way to break that, and a typo in a config file is a plausible route to it.

It survived because endpoint resolves as --endpoint ?? env ?? config, so a set FLAKEMETRY_ENDPOINT short-circuits the config lookup entirely. With the variable set — which is how CI is usually wired, and how every test exercised it — the bug is invisible.

run now resolves the config without raising and warns:

exit: 0
stdout: [TESTS RAN]
stderr: flakemetry: ignoring the config — invalid flakemetry configuration:
          - flaky.threshold: Number must be less than or equal to 1

A failing suite still exits with its own code (verified: exit 3 → 3), so the other half of the contract is intact.

config and doctor still refuse — telling you the configuration is wrong is their job, and shrugging would defeat it.

The stack trace

The validation messages were already excellent. They were buried inside a Node crash naming a bundled chunk, which is the wrong thing to hand someone whose file has a typo:

flakemetry: invalid flakemetry configuration:
  - flaky.threshold: Number must be less than or equal to 1
  - flaky.minSamples: Number must be greater than or equal to 1
  - quarantine.enabled: Expected boolean, received string
  - (root): Unrecognized key(s) in object: 'nonsense_key'

The tracker settings did nothing

FLAKEMETRY_TRACKER_ENABLED, FLAKEMETRY_TRACKER_AFTER_DAYS and FLAKEMETRY_TRACKER_RECOVERY_DAYS appear in POLICY_FIELDS, in docker-compose.yml, in deploy/compose/docker-compose.yml, in .env.example and in the configuration reference.

projectPolicyEnvOverrides mapped eight variables and none of those three. An operator setting FLAKEMETRY_TRACKER_ENABLED=true got nothing, and the Policy page reported the source as default while an environment variable said otherwise.

Proved before fixing:

expected { value: false, source: 'default' } to deeply equal { value: true, source: 'env' }

The new test walks every field the effective policy exposes and fails when one has no environment tier, so the next policy field cannot arrive half-connected.

How these were found

Not by reading. By running the documented commands against a live stack and checking what the product claims about itself — the same pass also confirmed the scope matrix, the export, badges, the CLI, both ingestion paths, every dashboard page and the webhook hardening, none of which needed changes.

62/62 turbo tasks.