ci: run the suite weekly against re-resolved dependencies

[Shashankss1205]

Every trigger on ci.yml was caused by someone pushing, so the suite only ever ran against the versions uv.lock pins. That is correct for a pull request and wrong as the only signal: a langgraph minor that breaks the runtime stays invisible here until a user on a fresh pip install grapharc hits it.

That is the standing complaint in #103 — every extra but mcp is unbounded, and the lockfile hides what the next major would do. With six weeks between commits there is currently no signal at all.

What this adds

• A Monday 06:00 UTC schedule trigger.
• One upstream-drift job that runs uv lock --upgrade to re-resolve every range from scratch, then syncs and runs the suite against the newest versions pyproject.toml's constraints allow.

Two deliberate choices

Gated to schedule and workflow_dispatch. On pull requests this would turn a contributor's branch red for an upstream release that branch did not cause. A PR has to be judged against the lockfile it ships.

The re-resolved lockfile diff is printed whether or not the suite then passes. A green run against moved dependencies is the useful half — it is the evidence needed to widen a range or drop a pin, which is what #103 actually asks for.

Noted in a comment on the trigger: GitHub disables a scheduled workflow after 60 days without repository activity, so a long quiet spell stops these runs rather than failing them.

Verification

ci.yml parses; the five jobs are lint, live-marker-guard, test, upstream-drift, build, and the cron expression round-trips. Full suite green locally on 3.14.7 — 2151 passed, 13 live deselected.

🤖 Generated with Claude Code

---

Follow-up commit: the job now reports where someone will see it

As first written this job had the flaw it exists to fix, one level up: it would detect upstream breakage and tell nobody. A scheduled run has no pull request to turn red and no author to notify.

This repository has already paid for exactly that. pages.yml failed on two consecutive pushes in August and the failures sat unnoticed for the better part of two months, while the published site served a version six releases behind. A weekly job in a repository that goes quiet for weeks is the same shape.

So a failure now opens an issue, or comments on the open one if there already is one — reused rather than re-opened, because an unattended weekly job that files a fresh issue every Monday is a second way of being ignored. Matched on title rather than a label, so it needs no label to exist first.

The body tells a reader what they need: that this is not any branch's fault, that every other job resolves against uv.lock while this one does not, that the remedy is an upstream fix or a narrower range in pyproject.toml (#103), and that the run log's lockfile diff names what moved.

issues: write is added at the job level, which replaces rather than extends the workflow's permissions, so contents: read is repeated there.

Verification

A reporting step that only runs on a failing Monday months from now is not something to take on trust, so I extracted the step's script out of the parsed YAML and ran it against a stubbed gh:

• the heredoc dedents correctly out of the block scalar, and the escaped backticks survive as literals rather than being command-substituted;
• $RUN_URL expands;
• with no open issue it calls issue create; with one open it calls issue comment and never issue create.