Fix/f alaska warnings

[d-diaz]

Description

Resolves 40 of the 41 compile warnings in f_alaska.f: type_conversion (29) and tab_character (11). No numerical change.

• type_conversion warnings are all one pattern — a REAL*8 coefficient or intermediate being narrowed on assignment to a REAL*4 variable — spread across three of the four routines (SHP_AK 11, COR_AK 1, VAR_AK 17; FDBT_AK is entirely single precision and warns only for its unused dummy). The narrowing is intended, and the code says so at line 162 (These outcomes are SINGLE precision), so it is now handled explicitly with REAL(). As in f_other.f there are no DATA literal fixes: F, SUBF and V are all genuinely REAL*8, so no DATA statement in this file warns at all.
• Nine of the wraps (lines 163–175) are byte-identical to lines already reviewed and accepted in this fork for f_west.f (Fix: f west warnings #14) — SHP_AK and the SHP_W* routines share that logit block verbatim, so most of this diff is a mechanical replay of an accepted change.
• SHP_AK lines 113–114 and VAR_AK line 393 are the trap in this batch, and they are worth a reviewer's attention. DMEDIAN, DFORM and DRATIO are declared REAL*4 here but REAL*8 in both sibling files (f_west.f:33,171,321, f_other.f:184,521) — which is exactly why the identical statements at f_west.f:74-75 and f_other.f:301-302,634-635 produce no warning. Widening the declarations to match is arguably the correct fix, but it would change every downstream U1–U9 value, so these are wrapped and the divergence is recorded as a latent defect instead.
• Line 114 is additionally the same trap f_other.f:876 had: its double precision comes solely from the 1.0d0 literal inside an arithmetic expression, not from a DATA initializer, so demoting it to 1.0e0 would evaluate the subtraction in single precision and could move results. Wrapped; literal untouched.
• tab_character was 11 leading hard tabs (lines 102–104, 107, 109–111, 233, 234, 368, 369), each replaced with exactly 6 spaces. gfortran's fixed-form extension already advances a column-1 tab to column 7, so every effective column is unchanged — a provable whitespace no-op. None of these lines carried a type_conversion warning, so the two edit sets do not interact.

Repo total 1,984 → 1,944; Tier A 240 → 211; no new warnings. f_alaska.f drops 41 → 1, the remainder being the unused setopt dummy in FDBT_AK, which cannot be dropped because sf_shp.f:28 dispatches it through the same signature as the other FDBT_* bark routines. Documented in warnings_progress.md rather than suppressed.

Five latent defects found while working in the file are recorded in the Reported to upstream separately table rather than fixed, since each would move numbers or change dispatch. The significant one is that SHP_AK patches its implicitly-SAVEd F array in place (lines 107–111) and never restores it, so the first GEOSUB=='01' spruce/hemlock call corrupts the coefficients for the life of the process. Measured on the pre-fix library, a single A01F32W098 call moves a subsequent A00F32W098 from 107.5 to 113.3 cuft (+5.4%) and 450 to 510 bdft (+13.3%), with two product fields collapsing to zero. It is currently unreachable through the shipped tables — the only A01 equations are A01BRUW202, A01DEMW000, A01DVEW094, A01DVEW375 and A01DVEW747, none of which satisfy VOLEQ(4:4)=='F' — so it is a latent landmine rather than a live bug, and f_ingy.f:280-300 solves the same problem correctly with a rebuilt scratch column. A fix is planned as Batch 1d, deliberately kept out of this PR so the no-op claim here stays clean.

Testing

None of the 57 existing goldens reached this file — every one is region 2, 3, 4, 6 or 9, and Alaska dispatch needs VOLEQ(1:1)=='A' with VOLEQ(4:4)=='F' and a species in {042, 242, 098, 260, 263, 264}. So 18 new cases were added and committed before any source edit: 12 vollib_r covering all four SHP_AK coefficient sets and all six FDBT_AK species branches across both the 2-point and 3-point entry paths, plus 6 getvoleq_r.

The vollib_r cases use A00F32W* / A02F32W* rather than hand-built strings, because those are the equations R10_EQN actually returns — so the 6 getvoleq_r cases assert the routing instead of it being asserted by hand. Doing that surfaced a gap worth flagging on review: tests/test_getvoleq.py only ever asserted one hardcoded case name, so the new lookups would have been recorded into cases.json and then never checked. It is now parametrized over every getvoleq_r case, which also brings a pre-existing case under assertion for the first time.

Coverage was measured rather than assumed. A gcov build confirms the 18 cases execute all 29 edited lines. Only one of them is conditional — line 168, under IF (U5 .le. 7.0d0) with R5=1.0 in the else — and it records 16 executions against 24 for its neighbours, so both branches are genuinely exercised rather than the line merely being reached.

Bit-exactness was checked the same way as #17: pre- and post-edit libnvel.so loaded side by side and called with identical inputs over 3,300 cases (all 12 reachable Alaska equations crossed with a dbh / height / merch-top / stump / upper-stem grid, including an upper-stem point below breast height), with all 15 vol[] components and errflag compared byte for byte. Every case matched. The sweep is smaller than the 12,960 of Batch 1b simply because Alaska has 12 reachable equations to f_other.f's 18; what makes the number meaningful is the harness check — perturbing F(10,1) in its 6th decimal produced 539 mismatches, and they fell exactly in the two species-042 equations, which is the precise blast radius for that coefficient.

pytest 86/86, warnings rebaselined, lint clean.