Add inventory-sensitivity gate before BrC chemistry/optics claims

[maxcharvey]

Problem

The wiki repeatedly flags fire inventory uncertainty as large enough to mimic or dominate BrC chemistry/optics changes. The current implementation tracker has code-level BrC/RRTMG issues, but no explicit gate requiring GFED vs inventory/scaling sensitivity before attributing model-observation changes to BrC physics.

Wiki basis

• wiki/projects/brc-modeling/current-brc-implementation-checklist.md: step 4, run inventory interaction check.
• registries/run_matrix.yml: BRC_VISCBLEACH_SCALE3X_WUS_OFFAOD, allowed inventories GFED, FINN, QFED, GFAS, SCALE3X_WUS.
• wiki/projects/validation/geos-chem-brc-validation-plan.md: compare fire inventory sensitivity before chemistry attribution.

Needed

• Define minimum inventory/scaling sensitivity after the first combined BrC branch passes short tests.
• Record which HEMCO configs and inventory versions are used.
• Keep western-US scaling separate from global default claims.

Acceptance

• BrC optics/lifetime improvements are not called production-ready until at least one inventory/scaling sensitivity has been compared.
• Run names follow BRC_<physics>_<inventory>_<operator>_<yyyymmdd>.

Wiki audit: [[brc-implementation-audit-2026-06-30#Validation]]

[maxcharvey]

Inventory-sensitivity gate not fully executed in this pass.

I kept the FFOCPI/FFOCPO split as requested and validated the combined model stack. I did not run a dedicated inventory-sensitivity matrix; keep this issue open for production science comparisons.

Branch: max/full_test.

Pinned commits:

• GCClassic: 475ffbd9cbf0adf0ee5f74eed06eb5e3739d1fe3
• GEOS-Chem: e586d1f207701ca31af2f50c55a26b5607c17664
• Cloud-J: 52407dbc3ab47874dafa7d9b87ed53ece3750945
• HEMCO: 3bdab085e8c6c5cf562a425251f655044ea7bb34

Validation completed:

• 1h fullchem scheme 4: pass
• 1h fullchem scheme 0: pass
• 1h RRTMG BrC smoke: pass
• 24h fullchem scheme 4 to 2019-07-02 00:00: pass
• StateMet-enabled offAOD prep run: pass
• offAOD Fortran core: pass

Caveat: a separate 0100->0200 restart mini-run hit HEMCO PS_NEXTDAY handling in the temporary met setup. The 24h run crossed the day boundary and wrote the final restart, so this does not look like a BrC-code issue.