nexrad: --pad-deg was accepted and silently ignored

[scottwmccoy]

Summary

• Every nexrad grid path (intensity_stack, reflectivity_composite, reflectivity_field/lowest_tilt_grid, beam_blockage) called load_aoi(aoi) bare, so the CLI's --pad-deg never reached the grid — outputs were silently clipped to the bare AOI bounds.
• Found by a consumer run, twice in one session: gridding the Hidden Valley 19 Jun 2026 storm, three wet gauges just outside the AOI polygon (incl. Six Mile Canyon, a debris-flow core gauge) fell off the grid, and a --pad-deg 0.06 re-run produced byte-identical bounds.
• AOI-level functions now take pad_deg (default 0.05, mirroring mrms.i15_storm_day) and forward it to load_aoi; the radar-object-level helpers (lowest_tilt_grid, beam_blockage) take pad_deg=0.0 as a pass-through; the CLI passes args.pad_deg at all three call sites. nearest_radar stays unpadded (a symmetric pad cannot move the centroid).

Behavior change

Default-flag nexrad grids now extend ~0.05° past the AOI, like the MRMS products always have. Since the AEQD grid is anchored to the padded extent, changing the pad shifts cell alignment — single-cell point samples in convective gradients can move ~2× (measured at HV; field statistics unchanged to two digits).

Test plan

• New plumbing probes in tests/test_nexrad.py pin the pad_deg each function hands load_aoi, plus the 0.05 default
• New CLI tests in tests/test_cli.py pin --pad-deg (and its default) reaching intensity_stack
• Full offline suite: 656 passed (pytest -m "not network")
• Real-data verification: the Hidden Valley hydro stack re-run with --pad-deg 0.06 now covers all 12 wet gauges

🤖 Generated with Claude Code