Storage keys need a structured (branch, period) scheme: str(period) is lossy and separators collide with branch names

#523 / #525 fix the crash where get_known_periods/get_known_branch_periods split storage keys on every colon, but the underlying key scheme has deeper, pre-existing structural problems (surfaced in cross-family review of #525):

1. str(period) is lossy for day-anchored periods. Keys embed f"{branch_name}:{period}", and Period.__str__ drops the day for e.g. month:2027-11-15:2 / year:2027-11-15:2, so distinct valid periods can collide in the cache and the readers reconstruct date-shifted periods.
2. Branch names have no enforced grammar. Simulation.get_branch accepts arbitrary names; a branch name containing : breaks split(":", 1) parsing in the readers and in delete.
3. OnDiskStorage has the same defect class with _ as the separator ({branch}_{period} + unconstrained split("_")): a branch name like my_reform mis-parses, and complex-period colons produce awkward filenames.

The clean fix is structured keys — (branch_name, Period) tuples in memory and an escaped/encoded filename scheme on disk — rather than string round-trips. That is a storage-format refactor deserving its own design + review, hence this issue rather than a rider on #525.

Start by tracing get_known_periods and get_known_branch_periods, then inspect Simulation.get_branch, delete, OnDiskStorage, and Period. Design structured in-memory keys using (branch_name, Period) and an escaped or encoded on-disk filename scheme. Done means distinct day-anchored periods and branch names containing separators round-trip without collisions or parsing errors.