motoko: core floor conflict (>= 2.5.0 vs "2.0.0+") and examples verified on a moc version below the skill's minimum

[raymondk]

• skills/motoko/SKILL.md:5 — compatibility: "moc >= 1.7.0, core >= 2.5.0".
• skills/motoko/SKILL.md:28 — "ALWAYS use: mo:core library version 2.0.0+".
• skills/motoko/references/examples.md:3 — "All examples verified with moc 1.5.0." — a compiler version the skill itself declares unsupported.

Both the core floor and the examples' verification claim should be brought in line with the frontmatter.

[raymondk]

The conflict is real, but resolving it is a policy call rather than a factual one, so I'm leaving it unclaimed with the evidence below.

What the examples actually require

I extracted the complete actor examples from references/examples.md and full-compiled them (moc -c) with --default-persistent-actors, which this skill's conventions require:

moc + core	ex1	ex2	ex3
1.5.0 + 2.0.0	OK	OK	OK
1.7.0 + 2.5.0	OK	OK	OK
1.8.2 + 2.5.0	OK	OK	OK

So the examples build fine on moc 1.5.0 + core 2.0.0 — the pair the frontmatter declares unsupported. That means :28 ("mo:core 2.0.0+") and examples.md:3 ("verified with moc 1.5.0") are consistent with reality, and it's the frontmatter floor that's above what the content needs. No example uses any post-2.0.0 core API (Principal.toActor, CallerAttributes, Base64, Float32, Array.toBlob, PriorityQueue — zero hits); every module imported (Array Bool Int Iter List Map Nat Order Principal Runtime Set Time Timer) exists in 2.0.0.

A wrong turn worth recording: my first run reported M0219 for all three examples on both pairs, which looks like the examples are broken. That was my setup — I'd omitted --default-persistent-actors, and these examples use plain actor { }, which needs it. Not a skill defect.

Why I'm not just fixing it

Only one of the three cited lines is ours to change. motoko tracks caffeinelabs/motoko, and neither :28 nor examples.md:3 is in the icskills-owned list in .claude/upstream.md — so editing them locally would create untracked divergence and needs an upstream issue plus an owned-sections entry. The compatibility: frontmatter is ours (it's in the sync checklist).

That leaves two coherent resolutions, and they point opposite ways:

1. compatibility means "minimum that works" → lower it to moc >= 1.5.0, core >= 2.0.0, matching the evidence and the body. Locally actionable, one line.
2. compatibility means "minimum we support/test" → leave the frontmatter and fix the body upstream, since claiming verification on a version you declare unsupported is incoherent either way.

I don't want to guess which, because it's a support-policy decision and it interacts with #297/#298 (mo:core and moc drift) — if those unify floors upward, option 1 would immediately be re-litigated. Happy to implement either once you've decided.

Minor, not a defect

examples.md's first actor example (the mixin/architecture one) doesn't compile standalone — import error [M0009], file "src/types/lib.mo" does not exist, likewise mixins/Auth, mixins/Blog. That's inherent to it illustrating the types.mo / mixins/ layout without shipping those files, and it's version-independent. Flagging only so nobody reads it as a regression.

Removing in-progress so this isn't left looking claimed.