Pin h5coro-hidefix at 0.3.0 in the Lambda layer (issue #170)

[espg]

Refs #170 (the pin-bump step of the read-path plan; the #154 pattern).

What

Bumps the two exact h5coro-hidefix pins from 0.2.0 to 0.3.0 — deployment/aws/build_layer.sh (the layer install) and the lambda extra in pyproject.toml (kept in sync with the layer per CLAUDE.md §7). The core dependency floor stays >=0.2.0 (0.15.0 workers run fine against either; requiring 0.3.0 semantics is a later-release decision).

Why

h5coro-hidefix 0.3.0 (espg/h5coro-hidefix#3, published today; manylinux_2_28 x86_64 + aarch64 wheels verified on PyPI) carries the two fleet-relevant changes: pooled per-chunk fetches in the sidecar read seam — the serial ranged GETs the 2026-07-07 manual benchmark showed dominating the read wall (cached column indistinguishable from the uncached baseline at ~195 s reads) — and flat-source sidecar support (read-plan-less products route through zagg 0.15's compiled full-read seam). Both sit behind the existing read_fn seam, so no zagg code change and no zagg release is needed: rebuilding the layer with this pin is the whole activation.

Testing

• tests/test_lambda_build.py: 31/32 pass; the one failure (TestFunctionBuild::test_function_build_succeeds) is the known environmental failure that reproduces identically on clean main (flagged during PR Force-cold Lambda dispatch option (issue #171) #172 verification) — not touched here, per §4.
• uv lock --refresh-package h5coro-hidefix resolves 0.3.0 cleanly for both 3.12 and 3.13 splits.
• The PR's lambda-build.yml run is the real gate (dual-arch layer build + the 250 MB combined-size check with the new wheel).

Deploy (espg, per §1)

Merge → rebuild + publish the layer (new version, currently :17) → point process-shard at it. Function zip unchanged (zagg 0.15.0). Then the fleet benchmark A/B (tdigest_healpix_o10_inner vs _cached) is the verification that the read column finally moves.