chore: bump to 0.11.0-SNAPSHOT for development

[arcaputo3]

Post-release hygiene: 0.10.0 is published to Maven Central and the GitHub Release is cut, so advance the default/dev publish version from 0.10.0-SNAPSHOT to 0.11.0-SNAPSHOT. Mirrors #53 (which bumped to 0.9.3-SNAPSHOT after 0.9.2).

PUBLISH_VERSION (set by the release workflow from the tag) still overrides this, so releases are unaffected; this only changes what local publishLocal / CI snapshot builds produce.

🤖 Generated with Claude Code

[claude]

Review

Scope is appropriately tiny: a single fallback bump in build.mill:71 from 0.10.0-SNAPSHOT → 0.11.0-SNAPSHOT. Nothing to flag on code quality, performance, security, or tests — there's no logic change here.

Verified

• PUBLISH_VERSION override claim holds. .github/workflows/release.yml:92,97 passes the tag-derived version into PUBLISH_VERSION, so Task.Input { Task.env.get("PUBLISH_VERSION").getOrElse(...) } only falls back during local publishLocal / CI snapshot builds. Tagged releases are unaffected, as the PR description states.
• Only file touched is build.mill. Grepping for 0.10.0 across *.{md,mill,scala,json,yml,yaml} returns the README badge + install snippets and the "0.10.0 Notes" changelog section in README only; no other build/config files need to move.

One thing worth confirming — divergence from #53

The PR cites #53 as the pattern, but #53 actually touched two files: build.mill and README.md (header badge + Mill/SBT/Maven install snippets all flipped 0.9.2 → 0.9.3-SNAPSHOT). This PR only touches build.mill. The README still advertises:

• README.md:6 — Scalagent \0.10.0``
• README.md:191,197,206 — Mill/SBT/Maven install snippets at 0.10.0

Two reasonable interpretations:

1. Intentional course-correction — pointing users at a SNAPSHOT in the README's "how to install" section is arguably user-hostile (they should pull the stable Maven Central artifact). Leaving the README at 0.10.0 is the better default. If so, the PR body's "Mirrors chore: bump to 0.9.3-SNAPSHOT for development #53" line is slightly misleading and could be reworded ("follows the post-release dev-bump pattern from chore: bump to 0.9.3-SNAPSHOT for development #53, but keeps README pinned to the published release").
2. Oversight — if you actually do want to mirror chore: bump to 0.9.3-SNAPSHOT for development #53 exactly, the README install snippets need to follow.

My read is that (1) is the right call and the README should not be bumped — but worth a sentence in the PR description either way so future-you doesn't wonder which convention is canonical when cutting 0.12.

Nit

Not blocking, but consider extracting the dev-snapshot string into a single constant or computing it from a release version + suffix, so the next bump is a one-character edit instead of a string replacement. Given how trivial these PRs are, totally fine to defer.

LGTM to merge once the README question is resolved (or acknowledged as intentional).