Feature 3247 link check

[jprestop]

Added automated link checking for METplus component documentation using Sphinx's built-in linkcheck builder, run via a new custom composite GitHub Action rather than duplicating workflow logic across each component repo.

Where linkcheck runs:
Linkcheck runs via GitHub Actions in each component repo, using a new workflow file, linkcheck.yml, which runs weekly (Monday 06:00 UTC via cron), fails the job on broken links so failures surface via GitHub's workflow notifications and runs on PRs touching docs/**, fails the job on broken links so new/edited links are checked before merge.

New shared component:

• Created dtcenter/metplus-action-linkcheck, a composite GitHub Action that installs docs dependencies, runs sphinx-build -b linkcheck, uploads the report as a workflow artifact, and fails/passes based on a fail-on-broken-links input (default true).
  • Note that this composite GitHub action differs from the other existing metplus-action-* repos (release-checksum, trigger-use-cases, data-update, etc.) in that they are Docker-based custom actions which predate composite actions being available on GitHub. Composite was the right choice here as the linkcheck action only needs Python, pip, and sphinx-build, all things that actions/setup-python and a shell run: step handle natively. A Docker-based approach would add image build/pull overhead and Linux-only constraints for no functional benefit, since there's no dependency here that needs container isolation.
• Each component workflow file just calls this action so there is no duplicated setup/install/build logic across repos. Updates to the action (retry logic, better failure parsing, etc.) propagate to every consuming repo by bumping a version tag.

Per-repo configuration still required:

• Each component's docs/conf.py needs a linkcheck configuration block (linkcheck_timeout, linkcheck_retries, linkcheck_workers, linkcheck_ignore, etc.). The contents of linkcheck_ignore are repo-specific, since each component links to different external resources, so this can't be centralized in the shared action and should be populated based on the first linkcheck run's actual output.
• No changes needed to docs/requirements.txt in any repository. linkcheck is part of core Sphinx, and the existing dependency list already covers everything needed to parse the doc tree.

Pull Request Testing

• Describe testing already performed for these changes:
  
  Ran sphinx-build -b linkcheck locally against the updated docs/conf.py. The new linkcheck.yml workflow (via the pull_request trigger) will run automatically once this PR is opened, since pull_request-triggered workflows execute from the PR branch rather than requiring the workflow to already exist on the default branch. This will serve as the first end-to-end test of the composite action against real repo content. The composite action itself (dtcenter/metplus-action-linkcheck) has not yet been tested independently prior to this PR. workflow_dispatch manual triggering is not testable pre-merge.

• Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  

1. Check the Actions tab on this PR for the linkcheck workflow run (triggered automatically via pull_request) and confirm it completed (either passing, or failing with a legitimate broken-link report rather than an action/configuration error). Note that the linkcheck workflow failed at the step "Run dtcenter/metplus-action-linkcheck@v1" with a legitimate broken-link report.
2. Download the [linkcheck-output](https://github.com/dtcenter/METplus/actions/runs/28908061175/artifacts/8155006783) artifact from that run and review output.txt to confirm the results look reasonable. I assumed we'd have a separate issue to go through each repository's broken links and clean them up and/or add them to linkcheck-ignore).
3. Ensure all tests pass, however, note that any use case test failures are unrelated to this work.
4. Review the updated documentation in continuous_integration.rst.
5. Review linkcheck.yml for the trigger conditions (schedule, pull_request with paths: ['docs/**'], workflow_dispatch).
   NOTE/QUESTION: workflow_dispatch (the manual trigger) won't be available to test until after this PR merges to the default branch (Do we want this added to the main_vX.Y branches also, or do we want to wait until for the METplus-13.0.0 coordinated release?)

• Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]

• Do these changes include sufficient testing updates? [Yes]

• Will this PR result in changes to the test suite? [No]
  
  If yes, describe the new output and/or changes to the existing output:
  

• Do these changes introduce new SonarQube findings? [No]
  
  If yes, please describe:

• Please complete this pull request review by [20260722].
  

Pull Request Checklist

See the METplus Workflow for details.

• Add any new Python packages to the METplus Components Python Requirements table.
• For any new datasets, an entry to the METplus Verification Datasets Guide.
• Review the source issue metadata (required labels, projects, and milestone).
• Complete the PR definition above.
• Ensure the PR title matches the feature or bugfix branch name.
• Define the PR metadata, as permissions allow.
  Select: Reviewer(s) and Development issue
  Select: Milestone as the version that will include these changes
  Select: Coordinated METplus-X.Y Support project for bugfix releases or METplus-Wrappers-X.Y.Z Development project for official releases
• After submitting the PR, select the ⚙️ icon in the Development section of the right hand sidebar. Search for the issue that this PR will close and select it, if it is not already selected.
• After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• Close the linked issue and delete your feature or bugfix branch from GitHub.

[coveralls]

Coverage Report for CI Build 28908061186

Coverage remained the same at 92.064%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	10471
Covered Lines:	9640
Line Coverage:	92.06%
Coverage Strength:	1.84 hits per line

---

💛 - Coveralls