Compare the keys that signed with the keys a linked GitHub account publishes, when asked

[felipesauer]

What

An identity can now name its GitHub account as a signed fact, and mnema verify --against-github compares the key each identity signed with against the SSH keys that account publishes at github.com/<name>.keys.

• New kind account.linked (FORMAT.md, vectors, schema, both readers: TS and the Python verifier accept it and refuse one without its account).
• New verb mnema key github <name>: records the claim, signed and checkpointed at once. No network.
• verify --against-github: per identity, either "the account publishes every key it signed with" or, by name, why not covered (no account linked, no such account, no Ed25519 key published, a key not among them, github.com unreachable). The flag is the only thing that reaches the network; the verdict, level and exit are the ones verify gives without it. fetch is injectable and has a short timeout; no test goes to the network.

Probe, base x head (sandbox HOME, env -i)

• Head verify without the flag on a record with no link: byte-identical to origin/main-v1's, exit 0.
• origin/main-v1's binary reading a record that holds an account.linked: FAILED — part of the record is UNREADABLE, naming the line and unknown event kind "account.linked", exit 1 (FORMAT section 4.1).

Known limits

• A binary from before this change refuses a record that holds an account.linked event (unknown kind), as above. Anyone who links an account makes the record unreadable to older binaries until they upgrade.
• What the comparison proves: the key that signed is one the account publishes today. What it does not: that the key was the account's when it signed (accounts add and drop keys), or anything without taking github.com's word for which keys an account has. Only a signed (checkpoint-covered) claim counts.
• Only Ed25519 keys are comparable; an account that publishes none reads as such.
• --workspace combined with the flag is refused rather than guessed at.