drift: uniprot_ptm cannot detect a UniProt release; hgnc/gencc have no corroborating signal

> **Corrected.** The first version of this issue listed five probes and claimed `expression_atlas`, `msigdb` and `uniprot_ptm` recorded no `source_version`. That was wrong — it came from grepping for `Content-Length` rather than reading what each probe actually returns. `expression_atlas` and `msigdb` are fine and are removed below. The real finding is narrower and sharper: **`uniprot_ptm` is blind to everything except the API's response shape.**

Some drift probes detect a *schema* change but not a *content* change, because the only thing they hash is a column-header or key list. Reading a fingerprint diff where the checksum is unchanged as "the data is unchanged" is therefore wrong — it means "the columns are unchanged."

## What each probe actually carries

| Probe | `source_version` (live value) | Checksum covers | Verdict |
|---|---|---|---|
| `uniprot_ptm` | **`None`** | keys of the *first result record* | **blind to content** |
| `hgnc` | `Last-Modified` | first line only | single unguarded signal |
| `gencc` | `Last-Modified` | header line only | single unguarded signal |
| `expression_atlas` | `"4562 experiments"` | full sorted projection of every experiment + `lastUpdate` | fine |
| `msigdb` | `"2026.1.Mm"` (upstream release) | release version | fine |
| `clingen` | *(deliberately none)* | header line | `Content-Length`, **fails closed** |
| `clinvar` | `Last-Modified` | — | `Content-Length` |
| `gwas_catalog` | `Last-Modified` | ETag + `Content-Length` | ETag + `Content-Length` |

## The actual problem: `uniprot_ptm`

Its fingerprint is:

- `source_version: null` — the UniProt REST endpoint returns no `Last-Modified`, and the probe records the `None` without comment.
- `checksums` — `sha256` over `sorted(results[0].keys())`, i.e. `['entryType', 'extraAttributes', 'features', 'genes', 'primaryAccession', 'sequence', 'uniProtKBCrossReferences']`.

Those keys are the **shape of the UniProt API response**, not the data. They change when UniProt changes its API, which is rare. There is no version, no count, no size, and no hash of any annotation content.

A UniProt release — roughly every 8 weeks, routinely adding and revising PTM annotations — would leave this fingerprint byte-identical and report `clean`. The probe cannot currently detect the event it exists to detect.

## Secondary: `hgnc` and `gencc`

Both hash only the header line and rely on `Last-Modified` as the sole content proxy. That works for a static file server, where replacing a file bumps the mtime — but it is unguarded: `head.headers.get("Last-Modified")` records `None` if the header ever goes missing, and the scheduled bot would commit that as the new baseline.

`clingen` already reasons about precisely this and refuses:

> If either the header row or `Content-Length` is absent the probe raises rather than recording a partial fingerprint, because the scheduled drift bot regenerates a drifted baseline automatically: a single transient omission would otherwise be committed as the new baseline and silently retire content detection for good.

This surfaced while triaging drift PR #266 (`hgnc:lookup`), where only `Last-Modified` moved (31 Jul → 4 Aug) with the column list byte-identical. It was merged on the reasonable assumption that an mtime bump means a new release — but the fingerprint gave no way to corroborate that.

## Proposed change

**`uniprot_ptm`** — needs a real signal, not a bigger header hash. Options, cheapest first: the result count from the same query; `extraAttributes.uniParcId` or a hash over a stable sample of accessions; or UniProt's release identifier if the API exposes one. Anything that moves when annotations change.

**`hgnc`, `gencc`** — record `Content-Length` in `extras` alongside `Last-Modified`. Both already issue a HEAD, so this is free on the wire, and it gives the corroborating signal `clingen` has.

Whether to fail closed should be decided per source rather than uniformly. Bump `PROBE_VERSION` for each probe changed; the comparator already ignores that key when diffing.

## Verification

Two consecutive probes per source, confirming the new signal is stable for unchanged content before it becomes a drift trigger — otherwise it reintroduces the "drifted on every run" failure `clingen` hit with `Last-Modified` and documented.

Follow-up from the 0.3.0 release. Not urgent — nothing is broken and no artifact is wrong — but `uniprot_ptm`'s detection is currently inoperative rather than merely weak.