chore(motoko): bump dev-env to v2.0.0, moc to 1.14.1, mo:core to 2.6.1

[marc0olo]

Summary

dfinity/icp-dev-env v2.0.0 bundles mops-cli 3.1.0 (and Rust 1.98.0). The mops-cli and writing-motoko ICP skills now state a compatibility floor of mops >= 3.1.0, moc >= 1.11.2, core >= 2.5.0 — every motoko example here was below that (mostly moc 1.8.2–1.13.0).

• Bump the dev-env container image pin (v1.2.0 → v2.0.0) in both guarded locations: .devcontainer/devcontainer.json and _run-example.yml.
• Bump moc to 1.14.1 and mo:core to 2.6.1 across all ~30 motoko mops.toml files, via mops toolchain use / mops add (never hand-edited).
• Fix the new compiler warnings the bump surfaced, per the writing-motoko skill: deprecated Blob/Array/Nat conversions replaced with dot-notation equivalents (.toBlob(), .toArray(), .toNat64()/.toNat8(), .toText()); redundant persistent removed from actor classes (verified empirically — see below); unused HTTP-outcall context params underscore-prefixed; var map bindings that are never reassigned changed to let; redundant ignore removed from Map.remove calls.
• Corrected an AGENTS.md caveat about actor-class persistence that turned out to be stale (see below).

Actor-class persistence finding: AGENTS.md used to say --default-persistent-actors does not propagate into spawned actor class sub-WASMs (e.g. canister_factory's Counter), so those needed persistent kept explicit. Under moc 1.14.1, moc itself now flags that persistent as redundant (M0217). I verified empirically rather than trust the warning blindly: dropped the keyword and ran canister_factory's full test.sh, including the test that adds to a spawned counter's value, upgrades it, and asserts the value survived — it passed. Same check on composite_query's Bucket. So the flag now covers actor classes too, and AGENTS.md has been updated to match.

Left as-is (not "fixed"):

• A few operator may trap for Nat (M0155) warnings on subtractions that are already correctly guarded by an immediately-preceding bounds check (icrc2-swap, random_maze, threshold-ecdsa/SHA256.mo) — moc's flow analysis can't see across the branch, but the code is safe and in one case already has a comment saying so. Rewriting a hand-rolled SHA256 or a balance-debit path to silence an advisory warning felt like the wrong risk/reward trade.
• An importing Candid service constructor as instantiated service warning (M0185) on three vendored third-party .did files (icp_ledger.did, icrc1_ledger.did, evm_rpc.did) used via --actor-id-alias/--actor-env-alias. Editing a vendored candid interface to satisfy a new moc parsing nuance seemed out of scope for this PR.

On ICP Ninja compatibility

None of this relies on any mops-v3-specific feature — [toolchain] pinning, [dependencies], [moc] args, and [canisters.<name>] are all mops CLI ≥2.2.0 syntax, and the moc/core version bump is orthogonal to the mops CLI major version. So this isn't gated on Ninja's build backend supporting mops v3 in particular. The residual, ordinary question — whether Ninja's backend (which doesn't use this repo's devcontainer/CI image at all) resolves moc 1.14.1 / core 2.6.1 cleanly — is a normal toolchain-bump consideration, not a blocker specific to this change.

Test plan

• mops check passes clean (bar the two categories of accepted warnings noted above) on all 34 motoko canisters across ~30 examples
• mops build succeeds on all 34 motoko canisters
• canister_factory's full test.sh passes locally, including the upgrade-preserves-state / reinstall-resets-state assertions
• composite_query's full test.sh passes locally (its Bucket actor class also lost its explicit persistent)
• CI green on this PR (dev-env v2.0.0)

🤖 Generated with Claude Code