MCGR and PINE blocked from the #73 provenance rollout — upstream fresh gaps

[NewGraphEnvironment]

Two of #73's 18 areas could not be run. Both are upstream fresh gaps, not provenance or
config defects — the freshness guard in 01_network_extract.R refused each before any
modelling. Neither has a data/<area>/provenance.json, so #73 cannot close until both are
resolved one way or the other.

Measured 2026-09-03. link's 2026-09-03 run (which added THOM/LNTH/UNTH) touched neither of
these.

MCGR — absent from fresh entirely

Freshness check: grabbed 0 km vs bcfp 937 km = 100.0% dev (tol 2%, guard=strict)
Error: network_source 'fresh' diverges from bcfp by 100.0% ... -- likely stale.

source	rows for MCGR
fresh.streams	0
fresh.streams_access	0
fresh.log	no row
fresh.streams_vw_bcfp	937 km ch-accessible, order >= 3

For contrast LSAL has 2701 / 10771. The config is correct — chinook genuinely is modelled there
in the reference (access_ch values 0,1,2; not the -9 not-modelled sentinel) — so this is not
the species/scenario mismatch #73 warns about. MCGR is listed in config/regions/fraser.yml
watershed_groups, so it is expected to exist and does not.

Needs: a link build covering MCGR into fresh. Then run_area.R mcgr (~20-40 min).

network_guard: warn is NOT a fix here — it would delineate a floodplain from zero streams.

PINE — present, but 10.8% below the reference

Freshness check: grabbed 2147 km vs bcfp 2407 km = 10.8% dev (tol 2%, guard=strict)

source	segments	km	mean seg
fresh.streams (grabbed)	8495	2147.1	253 m
fresh_default.streams	8509	2152.4	253 m
fresh.streams_vw_bcfp (reference)	8191	2407.1	294 m

What is ruled out

• Not a config difference. fresh.log for PINE reads config_name=bcfishpass,
  config_hash=sha256:19e3a0568842d, link_version=0.50.0 — identical to PCEA and PARS.
• Not a build-vintage cohort effect. PINE was built 2026-09-01 and its siblings 2026-09-02,
  but the other two WSGs built on 09-01 (LSKE, UTRE) are both at 0.0%.
• Not the documented bundle difference. default runs a median +0.7% OVER bcfp
  (subsurfaceflow left off). PINE runs 10.8% UNDER — the wrong direction.
• Not region-wide. Its two Peace siblings on the same schema, species and guard are at
  0.0% (pcea 2194/2194, pars 2310/2310).

Province-wide across 53 bull-trout groups, 47 agree within 0.5%. PINE at -10.8% is seven times
the next largest (UNRS +1.5%) and the only large negative.

The likely cause, and the open question

The two independently-built link schemas agree with each other (2147 and 2152 km, near-identical
segmentation) and both disagree with the reference (2407 km). config/regions/peace.yml records
PINE as handled out-of-band: "PINE (Pine River) was loaded via a link build... NOTE: it is NOT
in fresh.streams_vw_bcfp (the bcfishpass reference view was not refreshed)". That note is now
stale in its specifics — PINE is in the reference (42,885 rows) — so PINE's rows were added
to that table separately from the rest of it.

Open question: when, and from what, were PINE's rows loaded into fresh.streams_vw_bcfp?
That single fact decides the remedy.

• If the reference is the stale side (current working belief), then network_guard: warn in
  config/pine/area.yml is exactly what the guard's own error message prescribes, and PINE runs
  as-is — a one-line change.
• If fresh is the stale side, PINE needs a link rebuild like MCGR.

Also worth fixing while here

fresh.streams_vw_bcfp is a BASE TABLE, not a view, despite the _vw_ name. Both
fraser.yml and peace.yml justify the guard's ~0% passes as "a schema compared against a view
over itself -- it passes at ~0% deviation and verifies nothing". The mechanism is wrong: it is a
separately-loaded snapshot of the upstream bcfishpass model (4.27M rows, 188 WSGs, vs link's 97),
so the comparison is against a genuinely external reference. Measured on TABR and WILL, fresh
and the reference agree to 1e-9 m on total length with slightly different segment counts —
both select the same underlying FWA geometry, cut differently. The guard therefore detects
selection differences (barrier data, accessibility vintage), which is what staleness looks
like, and is a reasonable staleness detector — just not for the stated reason.

The snapshot carries no load date and no table comment, so "when was this last true?" is
unanswerable from the database. That is the whole reason PINE is hard to diagnose, and stamping
a load date beside it would make the next instance a five-second check.

Acceptance

• MCGR: built into fresh (or explicitly dropped from fraser.yml), area re-run, guard green
• PINE: cause established, remedy applied (network_guard: warn or rebuild), area re-run, guard green
• fraser.yml / peace.yml "view over itself" comments corrected
• A load date recorded for fresh.streams_vw_bcfp (or its refresh wired into the link run)
• Roll the #65 provenance fields out to the remaining 18 areas #73 closed

Split out of #73, which shipped 16 of 18 areas.

[NewGraphEnvironment]

Cross-reference from #79 (annual IO LULC series), which excludes PINE and now names this issue as the reason.

PINE's exclusion turned out to rest on something upstream of the network question this issue is about. data/pine/ has no provenance.json and its rasters/bt_ff04/*.tif are dated 2026-07-12, which predates flooded 0.5.0 — the bankfull-units vintage CLAUDE.md calls dead rather than superseded. So even setting network_guard: warn and re-running would not make PINE a step-3-only area: it needs steps 1-2-3 and a fresh baseline, which is a different shape of work from what #79 does to the other four.

For the record, PINE and MCGR are the only 2 of 23 area dirs with no provenance.json, and both have a pre-September floodplain — so the two really are the same case, which supports handling them together here.

Suggest adding to this issue's acceptance, after the fresh vs fresh.streams_vw_bcfp question is settled:

• PINE re-run with lulc_annual: true (Annual IO LULC series (2017-2023) for bulk, necr, lnth, kotl: rerun step 3 with every year #79's config key, already on main once that merges), so it lands with the full 2017-2023 series rather than needing a second pass
• Same for MCGR once it exists in fresh

That way neither area needs re-running twice, and the five-group set drift#62 wants is complete. No action needed on this issue for #79 to proceed — the four step-3-ready areas are independent of it.