toolchain: lint_source.py checks for integer(wp) and signed d-exponent literals (addresses #1485)

[BakaOverflow]

Description

I'm a CodePath AI301 student contributing to MFC as part of an open-source capstone project.

Why. MFC enforces several source conventions only through code review, so violations keep
landing in src/, and their failure modes are silent: a d-exponent literal such as 5.0d-11
hard-codes double precision and defeats MFC's build-time wp/stp precision switching, and
integer(wp) declares an integer with a real kind (a copy-paste slip). lint_source.py
had too narrow a regex for the first and no check for the second, so neither was caught.

What. This PR covers two of the three gaps in #1485 and fixes the violations they surface:

Linter (toolchain/mfc/lint_source.py):

1. Broadened check_double_precision's d-literal regex from [0-9]d0 to catch signed /
   multi-digit exponents (5.0d-11, 2.5d+3, 1.0d12). I constrained it with identifier
   boundaries — (?<![A-Za-z0-9_])[0-9]\.?[0-9]*[dD][-+]?[0-9]+(?![A-Za-z0-9_]) — because the
   bare pattern in the issue also matches the 2d12 inside identifiers like cart2d12_coords.
2. Added check_integer_wp — flags integer(wp), suggests plain integer.

Both registered in main(), with unit tests in test_lint_source.py.

Source fixes:

• m_bubbles_EE.fpp: integer(wp) → integer
• m_bubbles_EL.fpp: 5.0d-11 → 5.0e-11_wp

Deferred: the third gap — check_stop_statements — is intentionally left out of this PR. The
existing stops can't simply become s_mpi_abort (that routine is in m_mpi_common, which
already uses the modules the stops live in, so the import would be a circular dependency),
which is why the stop cleanup is tracked in #1483. I'll add the stop check in a follow-up
paired with #1483 so the check and the fixes land together.

@sbryngelson — two things I wanted to check with you. First, I tightened the d-literal regex from
the exact pattern in the issue by adding identifier boundaries, because the bare version also
matches names like cart2d12_coords; I believe that only removes false positives, but wanted to
flag the deviation. Second, I scoped this PR to the integer(wp) and d-literal checks and left the
stop/error stop check for a follow-up alongside #1483 — fixing those stops cleanly runs into
the module-dependency cycle that issue already owns. Happy to pull the stop check into this PR
instead if you'd prefer.

Addresses #1485. (Delivers two of the three requested checks; the stop/error stop check is deferred to #1483 — see "Deferred" above.)

Type of change

• New feature (linter checks)
• Refactor (source convention fixes)

Testing

Local (rebased branch, gfortran 13.3.0, CPU):

• python3 -m pytest toolchain/ → 368 passed (8 warnings, 4 subtests passed).
• python3 toolchain/mfc/lint_source.py → exit 0 (clean tree).
• ./mfc.sh precheck → all 7 local gates pass.
• ./mfc.sh build → exit 0 (all four targets).

Full CI — intra-fork dry-run on the narrowed commit (62a16ff2): 60 checks passed, 1 failed.

• ✅ CPU test matrix green — every NVHPC-cpu and Github (ubuntu/macos, GNU/Intel) job passed,
  Lagrange bubble cases included (the family an earlier full-scope attempt broke, now clean).
• ✅ Coverage Test on CodeCov green; ✅ NVHPC GPU jobs green; ✅ lint / spell / convergence /
  FP-stability all green.
• ❌ Only red: Build & Verify, at its Linkcheck - Lychee step — a [403] on a StackOverflow URL
  in docs/documentation/docker.md, a file this PR does not touch and which is unchanged on
  master (pre-existing; not caused by this PR).

Before / after — the gap this PR closes (verbatim linter output):

# BEFORE: on master, the linter reports success despite the violations
$ python3 toolchain/mfc/lint_source.py; echo exit=$?
exit=0

# WITH THE NEW CHECKS (this PR), before fixing the sources — they are caught:
$ python3 toolchain/mfc/lint_source.py
Source lint failed:
  src/simulation/m_bubbles_EL.fpp:1799 double-precision intrinsic '5.0d-11'. Fix: use generic intrinsics and wp/stp kind parameters
  src/simulation/m_bubbles_EE.fpp:73 'integer(wp)' uses a floating-point kind. Fix: use plain 'integer'

# AFTER: sources fixed in this PR, tree is clean again
$ python3 toolchain/mfc/lint_source.py; echo exit=$?
exit=0

Checklist

• I added or updated tests for new behavior
• I updated documentation if user-facing behavior changed (no user-facing behavior changed)

GPU changes

integer-kind + literal-form changes only; no GPU logic; flagging for the CI matrix.

[BakaOverflow]

@claude full review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.21%. Comparing base (782a1fd) to head (62a16ff).
⚠️ Report is 13 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1725      +/-   ##
==========================================
+ Coverage   61.04%   61.21%   +0.16%     
==========================================
  Files          83       84       +1     
  Lines       20978    21601     +623     
  Branches     3099     3195      +96     
==========================================
+ Hits        12807    13223     +416     
- Misses       6126     6209      +83     
- Partials     2045     2169     +124     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.