check: certify a run over the ecosystems that did answer, rather than all-or-nothing

[justin13888]

Out of #112, which shipped the granularity but deliberately not this.

What #112 shipped

ManifestCheck now carries unreachable_registries: Vec<UnreachableRegistry> — which
registries declined to answer, named per route rather than per manifest — and the
--fail-on refusal names them:

error: cannot honour --fail-on: the Go and npm registries did not answer

That is a granularity change only. The gate's promise is unchanged: if any registry
anywhere in the run declined, gate_is_answerable refuses to certify the whole run and
the process exits 2.

What is still coarse

#112's second bullet was that "a future opt-in could let a run be certified over the
ecosystems that did answer, rather than all-or-nothing". A polyglot monorepo whose Go
proxy is down still exits 2 even though the npm, Python and Rust manifests were checked
against registries that answered every request. The routing key needed to express that
now exists; the policy does not.

Why it was not built with the granularity

Two reasons, both recorded in #112's pull request:

1. It changes what --fail-on promises, not how precisely it reports.
   gate_is_answerable's doc comment is an argued position — "a promise not to pass a
   build with a particular property, and a run that failed to look cannot keep it".
   Weakening that needs the argument made and the new promise written down, not a flag
   added beside the old one.

2. An unresolved semantic. A manifest is not the routing unit. When one Cargo.toml
   routes to crates.io and to a private alternate registry and only one of them answered,
   which of that manifest's results are certified? Its dependencies are not partitioned
   by ecosystem — they are partitioned by route, and a reader of the exit code cannot see
   that partition. The same question applies to a deno.json reaching npm and JSR.
   Answering it is the substance of this issue.

What closing this needs

• A decided answer to the partition question above, written into
  gate_is_answerable's contract.
• A surface for the opt-in. Note that check: make registry_unreachable per-ecosystem rather than per-manifest #112 deliberately added no CLI flag, config key,
  or output field, so this issue owns the first one.
• A statement of what a passing exit code then means, since it would no longer mean
  "every dependency in this run was evaluated".
• Tests covering the mixed case: one manifest, two routes, one answered.