The Moonraker pin was frozen by a missing _sqlite3 we now build ourselves

MOONRAKER_VERSION was 9d0d09d, the last commit before 80c7620 moved the
database from lmdb to sqlite, because FlashForge's python 3.8.2 has no
_sqlite3 and every release after it died loading the database component.
This repo builds and ships its own CPython 3.13 now, and it has one. The pin
is v0.11.0 -- a release tag, not a sha, so PKG_VERSION is just 0.11.0 and no
longer the Debian-style 0.8.0+git<sha> snapshot string. GitHub strips the
leading "v" from the directory inside /archive/<tag>.tar.gz, which is what
${MOONRAKER_VERSION#v} in the recipe is for.

The dependency set is the part that actually moved. Read against 0.11.0's
CORE_COMPONENTS plus the sections moonraker.conf enables:

  dbus-next became dbus-fast. dbus_manager is a core component and imports
  it at module scope, so this is not optional whatever [machine] provider
  says. Its sdist cythonises nine modules; SKIP_CYTHON=1 ships the python
  they were generated from and keeps the package ARCH all. The wheel still
  comes out platform-tagged -- poetry-core marks the distribution impure
  for declaring a build script at all -- but it holds 29 .py and no .so,
  and the content is what ships.

  importlib-metadata is new, imported at module scope by
  utils/source_info.py, and brings zipp. Both build through setuptools_scm,
  so PYPKG_HOST_LIST grew packaging and setuptools-scm. That list is now
  install order: pkg_buildpython pip-installs each with --no-deps against
  no index, flit-core builds packaging, setuptools_scm imports it.

  pyserial-asyncio is gone. Nothing in 0.11.0 imports serial_asyncio;
  utils/async_serial.py drives pyserial over asyncio itself. pyserial stays
  -- klippy needs it and declares it.

LMDB STAYS, for a reason that is not the old one. 0.11.0 converts an
existing data.mdb to sqlite on first start and imports lmdb to read it. With
the module missing it tries to pip install one, and a printer has no index
to install from -- the old database would be dropped in silence. It is the
upgrade path now, not the database, and the comment on WANTED_MODULES says
so.

inotify-simple STAYS AT 1.3.5 though 0.11.0 pins ==2.0.1: 2.0.1 declares its
licence the PEP 639 way and needs setuptools>=77 to build, against the 75.6.0
pinned here for lmdb's sake. It fails at metadata generation, not at import,
which is the kind of thing that reads as a broken recipe later. 1.3.5 carries
every name 0.11.0 asks of it, and moonraker.conf sets file_system_observer:
none, so the import is all that is asked. jinja2 goes to 3.1.6 to match.

Not taken: paho-mqtt, zeroconf, apprise, ldap3 and python-periphery, whose
components this printer does not enable, and msgspec and uvloop, which
Moonraker imports under contextlib.suppress(ImportError).

Verified: every changed sha256 downloads and matches at the URL
fetch-assets.sh builds; all five affected wheels build offline
(--no-index --no-build-isolation) on a real 3.13 with the host backends
installed in the declared order; qa/static 122 passed, including the gates
that cross-check PYPKG_LIST against the recipes and every PKG_DEPENDS
against the feed. The mipsel cross-build and `make qa-replica` have not run
yet, and versions.env still says a bump is gated on the latter.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012oRdgKM7scrEsr6waAByaY

docs/how-it-works.md

@@ -136,7 +136,7 @@ never invoked — the moonraker service starts the server itself.
 **FlashForge's python 3.8.2 is not what this runs on any more.** `FF_PYTHON`
 in `anvil-env.sh` names a CPython 3.13 of our own, cross-built for mipsel by
 `pkgs/3rdparty/python`, with every third-party C extension Moonraker needs beside it in
-`$MODDIR/lib/python3.13/site-packages` — eighteen packages, one `pkgs/3rdparty/python-*`
+`$MODDIR/lib/python3.13/site-packages` — nineteen packages, one `pkgs/3rdparty/python-*`
 recipe and one `.ipk` each — and libsodium in `$MODDIR/lib`; none of it
 borrowed from `/usr/prog`. Measured through the
 real boot path (the scandir, the moonraker service, readiness gating on `:7125`
@@ -144,19 +144,26 @@ actually listening, a `kill -9` respawn, a stop that stays stopped). klippy is o
 too: the `klipper` service execs `$FF_PYTHON` against the klippy tree in
 `$MODDIR/klipper`, so both halves are ours.
 
-**The Moonraker commit pin is still a 2023 one, though the reason it exists
-has changed.** FlashForge built python 3.8.2 without the `_sqlite3` module,
-and Moonraker moved its database from lmdb to sqlite in v0.9.0, so on 3.8.2
-every release from there on got as far as loading the database component and
-died with `ModuleNotFoundError: No module named '_sqlite3'`. Our 3.13 has a
-working `_sqlite3` (measured: create, insert, select, reopen -- and exercised
-for real every run, since Moonraker itself comes up on it in
-`qa/replica/test_web.py`), which is what unpins this -- but the pin has not moved yet: nobody
-has taken a newer Moonraker through this build and its replica gates, and a
-version bump is exactly the kind of change that wants its own measurement,
-not a side effect of an interpreter switch. Until it does, the printer's lmdb
-store is used in place -- nothing is converted, and reverting to stock is a
-clean round trip.
+**Moonraker is a release now, `v0.11.0`, and no longer a 2023 commit.**
+FlashForge built python 3.8.2 without the `_sqlite3` module, and Moonraker
+moved its database from lmdb to sqlite in v0.9.0, so on 3.8.2 every release
+from there on got as far as loading the database component and died with
+`ModuleNotFoundError: No module named '_sqlite3'`. Our 3.13 has a working
+`_sqlite3` (measured: create, insert, select, reopen -- and exercised for real
+every run, since Moonraker itself comes up on it in `qa/replica/test_web.py`),
+which is what unpinned it.
+
+Upgrading a printer that has run an older release **converts** its database:
+Moonraker reads the existing `data.mdb` once and writes an sqlite store beside
+it, which is why `anvil-python-lmdb` still ships even though nothing imports
+lmdb at runtime any more. Without that module Moonraker tries to `pip install`
+one, and a printer has no index to install from -- the old database would be
+dropped in silence. Reverting to stock is still a clean round trip: the lmdb
+store is read, not deleted.
+
+The dependency set moved with it. `dbus-next` became `dbus-fast`,
+`importlib-metadata` (and its `zipp`) is new, and `pyserial-asyncio` is gone,
+imported by nothing in 0.11.0.
 
 This was not worked out in advance; v0.9.3 was built, shipped and tried on the
 printer first, and that is what it said. What came out of it: when bumping the