Pin BrC submodule pointers for reproducible builds

[maxcharvey]

Problem

The wiki records repeated submodule drift: builds/runs can silently use the wrong GEOS-Chem, HEMCO, or Cloud-J branch/commit. This made resolved BrC AOD/Cloud-J issues appear unresolved and makes run provenance hard to audit.

Current known BrC branches

• GEOS-Chem: max/brc for chemistry baseline; max/online_AOD for separate AOD bins; max/brc-pbrcpoa-omoc for PBRCPOA split review
• HEMCO: max/brc for BrC GFED species; max/injection_height for injection-height runs; max/brc-pbrcpoa-omoc for PBRCPOA split review
• Cloud-J: max/brc-array-dims for BrC Cloud-J array dimensions

Needed

• Decide which branch/commit combination is the canonical build for each run family.
• Commit superproject gitlinks for those canonical combinations.
• Document a quick pre-build check in the run workflow.
• Avoid relying on dirty/manual submodule checkouts for production runs.

Acceptance criteria

• Fresh clone + git submodule update lands on the intended BrC-compatible submodule commits.
• Build properties/run notes identify the exact superproject and submodule SHAs.
• No production run relies on a locally drifted submodule state.

[maxcharvey]

Submodule pointers pinned on max/full_test.

GCClassic commit 475ffbd9cbf0adf0ee5f74eed06eb5e3739d1fe3 points at the GEOS-Chem, Cloud-J, and HEMCO commits listed below. All four max/full_test branches were pushed.

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.