A constant's name is now a purely syntactic transformation of the name of
the `Literal` type it manifests, so the format version comes first and is
spelled `ZARR_V2`/`ZARR_V3`, matching the `ZarrV2`/`ZarrV3` prefix already
used by type names. This replaces the 0.4.0 split under which types put the
version first and constants put it last; there is now one rule instead of
two. Nine constants are renamed without aliases (pre-1.0).

Digit runs stay glued to the token they follow, which keeps the spec
vocabulary intact: `Uint8DataTypeName` pairs with `UINT8_DATA_TYPE_NAME`,
not `UINT_8_...`, and `Crc32cCodecName` with `CRC32C_CODEC_NAME`. No dtype,
codec, chunk-grid, or chunk-key-encoding constant changed name. A strict
letter/digit split would have renamed 18 of them for the worse.

Store keys also move to the modules describing the documents they name.
They are facts about the on-disk specs, so they belong beside the types
they key: `ZARR_V2_ATTRIBUTES_STORE_KEY` now lives in `v2/attributes.py`
next to `ZarrV2ZAttrsJSON`, rather than in the array model. This keeps the
`v2`/`v3` packages as leaf spec-description modules that never import from
`model`, and drops the `_group.py` -> `_array.py` import of a key that was
never array-specific. `zarr_metadata.model` re-exports all of them, and
they are now also exported from the top-level namespace alongside the rest
of the spec vocabulary.

`CONSOLIDATED_METADATA_KEY_V3` is renamed and moved likewise, but is not a
store key: v3 consolidated metadata is embedded as an extension field in
the group's own `zarr.json`, so it has no paired `Literal` alias and is not
passed to the store-json helpers.

Three tests pin what the refactor made implicit: constant names are derived
from their types mechanically, the two v3 node store keys still name the
same file now that they live in different modules, and the set of
value-ambiguous constants the derivation check cannot see is counted so its
coverage cannot shrink unnoticed.

Assisted-by: ClaudeCode:claude-opus-4.8