git-refs: shard every checkpoint ID on the last two chars (one rule for both formats)

ShardFor previously branched on the ID Kind — legacy hex on the first two chars, ULID on the last two — which meant the ref shard depended on format detection and could be computed inconsistently by an independent reimplementation (the e2e helper sharded any 26-char string as a ULID, diverging from production's strict check for a 26-char non-ULID).

Collapse it to a single positional rule: the last two characters, for both legacy 12-hex IDs and 26-char ULIDs. Trailing chars are uniformly random in both formats (a ULID's leading chars are its timestamp), so distribution stays even, and there is no Kind branch to get wrong. RefName still rejects KindUnknown IDs, so both supported formats map to a proper ref while invalid ones are refused.

This only affects the git-refs ref namespace (no production data yet); the entire/checkpoints/v1 branch tree keeps its independent first-two Path() layout. The e2e checkpointShard helper is simplified to the same last-two rule so it can't diverge from production. Updates the affected shard expectations in the id, refs-naming, and refs-store tests.

Resolves the git-refs sharding review thread (e2e/testutil/backend.go).