fix: reject malformed chunk keys in DefaultChunkKeyEncoding

[d-v-b]

🤖 AI text below 🤖

What

DefaultChunkKeyEncoding.decode_chunk_key stripped a single leading character and split the rest, so any string decoded to something rather than being rejected:

>>> enc = DefaultChunkKeyEncoding(separator="/")
>>> enc.decode_chunk_key("0/1")   # not a chunk key for this encoding
(1,)                              # the "0" was eaten as if it were the "c" prefix

The same applies to a key written with the other separator: under separator="/", the key c.0.1 decoded via a path that never checked the prefix it was documented to require.

This validates the c<separator> prefix and raises ValueError when it is absent, so a string that is not a chunk key for this encoding is reported instead of silently misread.

Why it matters

The failure was silent and produced plausible-looking coordinates, so a caller validating a key by "does it decode?" got the wrong answer rather than an error. Anything mapping untrusted or foreign keys onto a chunk grid — a server, a translating store, a validator — inherits that.

Compatibility

This is a behavior change: input that previously returned garbage now raises. Nothing in the test suite depended on the old behavior — the full suite passes unchanged (6647 passed) — but it is worth a reviewer's eye in case a downstream caller was relying on the lax parse.

Tests

decode_chunk_key had no direct test coverage. This adds tests/test_chunk_key_encodings.py: the round trip for both separators and several chunk shapes, one test per way a key can fail to carry the prefix, and the v2 encoding's documented 0-d asymmetry (encode(()) == "0" while decode("0") == (0,), which is inherent — "0" is ambiguous between a 0-d array's sole chunk and a 1-d array's chunk 0, and only the array's rank disambiguates it).

🤖 Generated with Claude Code