Nightly Rust coverage cannot plan its shards: flags lookup raises KeyError on any unmapped shard

[jeremi]

Symptom

Nightly Rust coverage fails in its first job, Plan Rust coverage shards, so every coverage
shard is skipped and no coverage is produced at all.

Traceback (most recent call last):
  File "<stdin>", line 30, in <module>
KeyError: 'discovery'

Cause

.github/workflows/nightly-rust-coverage.yml builds its matrix from the shared shard inventory:

flags = {
    "platform": "platform",
    "manifest": "manifest-unit",
    "developer-tools": "developer-tools",
}
matrix = [
    {..., "flag": flags[name]}
    for name, packages in SHARDS.items()
]

It iterates every entry in SHARDS but indexes flags unconditionally. flags only carries the
shards whose flag name differs from the shard name, so any shard absent from it raises KeyError.
SHARDS in .github/scripts/ci_changes.py contains discovery, relay-client, relay-v2,
evidence, and mint beyond those three, and discovery is simply the first one reached.

Adding a shard to ci_changes.py silently breaks this workflow, because nothing ties the two
together.

Suggested fix

flags.get(name, name) expresses the actual intent: the shard name is the flag name unless the
mapping overrides it. That also makes the workflow survive the next shard someone adds.

Worth considering alongside it: have the planner fail loudly with a message naming the unmapped
shard rather than a bare KeyError from a heredoc, or assert the two inventories agree, so the
next divergence reports itself.

Provenance

Noticed while checking that main was healthy before cutting a release. Pre-existing and unrelated
to #785 or #786. Not a release gate, so it does not block the release.

Not fixed here: .github/scripts/ci_changes.py has uncommitted local changes in a working tree, so
this area looks actively worked on and a drive-by edit could collide.