Stop committing lock files; add weekly CI safety net

[marc0olo]

Closes #1457. Resolves the inconsistent lock-file handling and makes examples resolve current dependencies on clone.

The problem (verified against master)

• 30 Cargo.lock + 1 mops.lock are committed, yet both are gitignored — the tracked ones are overrides, so the policy is inconsistent.
• No build depends on them: nothing sets locked: true in any icp.yaml, and there's no --locked/--frozen anywhere except the CI tool bootstrap (cargo install --locked for candid-extractor/wasi2ic, which use the tool's own lock).

Decision: don't commit lock files

A developer cloning an example should get the latest semver-compatible dependencies (per each Cargo.toml/mops.toml range), not a stale pin — matching the repo's stay-current philosophy. Since the locks aren't load-bearing, removing them changes nothing about how builds run today; it only lets resolution pick current versions.

• Untracked all 30 Cargo.lock and the 1 mops.lock (git rm --cached; both already in .gitignore, so they stay ignored). package-lock.json was already gitignored.

Safety net: weekly CI

Without locks, a bad upstream patch could break an example with no repo change — and only surface when someone touches it. So every example workflow (and workflow-template.yml) gains a weekly schedule trigger (cron: "30 6 * * 1"), building/deploying/testing all examples every Monday.

• Chose per-workflow schedule (not a new aggregate workflow) so each run reuses its example's exact config — pocketic, deploy.sh, cycles, language — with no duplication or drift, and new examples inherit it from the template.

AGENTS.md documents both the no-lock-files policy and the weekly run.

Notes

• All 63 modified workflows validate as YAML.
• Removing the 30 locks means those examples' next CI run resolves fresh deps for the first time — if anything was silently pinned to an old transitive version, the weekly run (or this PR's CI) will surface it. That's the intended signal.

🤖 Generated with Claude Code

[mbjorkqvist]

Thanks for looking into this, @marc0olo! Looking at the referenced issue #1457, I'm curious why you didn't go for option a, with e.g., a weekly dependabot run? What happens if the weekly CI check now fails, would that require manual intervention to e.g., fix an example to work with the latest version of some dependency? Maybe I'm missing something, e.g., how things may be significantly different in this repo with lots of examples, a mix of Rust and Motoko, and icp-cli?

[marc0olo]

@mbjorkqvist my personal take on this is mainly that we would have a lot of noise on the repo and generally we want everybody who clones and runs the examples to automatically resolve the latest patch versions which isn't the case if we define strict versions in the lock files.

either way, our goal should be to keep the dependencies on this repo up to date. we need to figure out the best way to handle that efficiently.

would that require manual intervention to e.g., fix an example to work with the latest version of some dependency?

we will see, but ideally the CI never fails for the examples (although I recognized some flaky tests already which I still need to look at, they usually pass on a 2nd run). for the UI we don't have integration tests. but at least compilation + deployment and in many cases also backend functionality is tested via CI.

of course we should aim to avoid manual intervention. (e.g. dependabot PRs would also have to be handled by "someone", whether it is an agent or a human)

wdyt?