Decision: should link checking and Colab checks move from per-repo workflows into shared actions?

[quantecon-services]

The choice. docs/dev/PLAN.md records a settled decision: "collab.yml and linkcheck.yml remain standalone workflows". Two issues filed on 2026-09-24 propose the opposite, carried over from the deleted FUTURE-DEVELOPMENT.md (#182):

• New action: shared link checker for lecture sites #184: a shared link-checker action wrapping lycheeverse/lychee-action, replacing each repo's linkcheck.yml;
• New action: Colab compatibility check for lecture notebooks #185: a shared Colab compatibility-check action, generalising lecture-python.myst's collab.yml.

Neither can start until the settled decision is either reopened or confirmed.

Evidence to gather before deciding (both issues' first checklist items):

• Survey the lecture repos' linkcheck.yml files. How many are there, how far have they drifted, and what does each one exclude?
• Who runs a Colab check today? Only lecture-python.myst is known. Would others adopt one?
• How would a shared Colab check report failures caused by Colab's unpinned :latest runtime rather than by the lecture?
• Reuse: both would file a deduplicated issue the way build-jupyter-cache does. Would that step be extracted and shared?

Outcomes.

• Yes, for either or both: update the PLAN.md line, then build under a "published-site checks" project. ENH: standalone execution check of built notebooks #2 (standalone execution of built notebooks) is its natural third member.
• No: close New action: shared link checker for lecture sites #184 and/or New action: Colab compatibility check for lecture notebooks #185 as not planned, pointing at this issue. PLAN.md stays as it is.

Related: #115 is prior art (lychee); #96 is a similar reopening of a settled PLAN decision, the .notebooks repos.