feat(zarr-metadata): export base64_fill_value_rules for data type definitions - #4609

Export base64_fill_value_rules from zarr_metadata.v3.data_type.bytes, the rule that rejects a fill value string that is not standard-alphabet base64, so a data type defined outside the package can pass it as fill_value_rules for a Base64Bytes fill value, or yield from it in a rule of its own. The guide to parsing and validation now shows how to define a data type with fill_value_rules.

Refs d-v-b#425. The issue asks for a way to constrain a fill value beyond its JSON type. fill_value_rules already does that, and both the reader and the pydantic field apply it. The consumer's definition only set fill_value=str, the guides never mentioned fill_value_rules, and the package's base64 rule was private. This PR fixes the last two.

• base64_fill_value_rules (in v3/data_type/_byte.py) fits the fill_value_rules slot and checks only strings, so it also serves bytes, whose fill value may be written as byte values. bytes and variable_length_bytes now use it in place of their own copies. null_terminated_bytes and zarr_python_raw_bytes still call base64_problems directly before their size checks.
• docs/parsing-validation.md gains an example: an acme.packed data type whose rule yields from base64_fill_value_rules and then checks the size its configuration sets. It adds the type with CORE_AND_EXTENSIONS_CONTEXT.union(ZarrV3Context(data_types=[PACKED])), and runs in the docs tests.
• JSON Schema still does not carry rules, as the json_schema module documents, so a schema for such a context accepts any string.

The agent rebased this onto main as one commit: the branch had been stacked on the ZARR_PYTHON_CONTEXT branch, which merged upstream as #4583, and the docs example switched from the removed context.update(...) to union. just check in packages/zarr-metadata passes (3696 tests and the strict docs build).