bump-mthds

# Bump the `mthds` dependency

`mthds` is the MTHDS standard's Python client: the protocol wire models, the
runner abstracts, the package-manifest schema. This engine is built on it
directly — it subclasses its abstracts (`StuffAbstract`, `ConceptAbstract`,
`WorkingMemoryAbstract`, `MTHDSProtocol`) and **re-exports its wire models as
part of pipelex's own public surface** (`pipelex/pipeline/input_form.py` and
`pipelex/pipeline/pipe_io_contracts.py` list them in `__all__`).

That last part is what makes this bump different from bumping an ordinary
dependency: an upstream rename is not an internal detail this repo absorbs, it
is a **breaking change to pipelex's own API**, and it has to reach the changelog
as one.

The job is to land the new pin in a state a human can read and commit: pin
moved, lock regenerated, source adapted, checks green, changelog written, ledger
squared. **Stop before committing** — the user stages and commits.

## What the bump touches

| File | Why it moves |
|---|---|
| `pyproject.toml` | The pin itself, one line in `[project].dependencies` — `mthds==X.Y.Z` |
| `uv.lock` | Regenerated by `make li` |
| `pipelex/**` | Wherever the new release renamed, split, or tightened something this engine imports |
| `tests/**` | Same, plus any test asserting on a shape that moved |
| `CHANGELOG.md` | An entry under `## [Unreleased]` — always at least the pin line |
| `.badges/tests.json`, `.test_durations` | Only if the adaptation added, removed or renamed tests |

Do **not** touch `[project].version`. That is this package's own version and it
moves only at release time, via the `release` skill.

## The pin is exact, and it always tracks latest

The pin is `mthds==X.Y.Z`, not `>=`. That is deliberate and it is newer than it
looks — the dependency was a `>=` floor until v0.54.0, which moved it to an
exact pin and recorded the move as a breaking change. **Never relax it back to
`>=` while bumping**, and never widen it to get a resolve unstuck.

The reason is what this engine does with mthds: it re-exports mthds' wire models
as part of pipelex's own public surface, so a consumer resolving a different
mthds would be handed one version's classes through the `__all__` of a pipelex
built against another — `isinstance` narrowing over a protocol union failing in
a way no version specifier explains. An exact pin makes the version this repo
tests against the version it demands, with no gap for a consumer to fall into.

**The standing policy is to move the pin to the latest release, every time**,
even when the new release carries nothing this engine uses. The cost is real and
worth naming when you report: everyone downstream — `pipelex-sdk-python`,
`pipelex-server`, every user install — is forced onto that exact `mthds`, and a
consumer that also depends on `mthds` directly must now move in step with
pipelex rather than resolving its own. Say so in the changelog when the bump is
otherwise uneventful, because for a consumer "pipelex now requires mthds
0.11.2" *is* the change.

## Three numbers, none of which is the others

This is the single most common way to get confused here, and two of the three
are visible in the same sentence of an upstream changelog.

| Number | Where it lives | What it means |
|---|---|---|
| The **`mthds` package version** | `mthds-python/pyproject.toml`, PyPI | The Python client's own release number. **This is what you are bumping.** |
| The **MTHDS standard version** | `MTHDS_STANDARD_VERSION` in `mthds/package/manifest/schema.py` | The version of the *standard* that client implements. Currently `1.0.0`. |
| The **spec site's release number** | the `mthds/` repo's own CHANGELOG | The documentation site's release, e.g. `v0.9.0`. Coincidentally close to the package number; unrelated to it. |

So "mthds 0.9.0 ships the artifacts the standard owns since MTHDS v0.9.0, which
is standard version 1.0.0" is a coherent sentence. Read every version reference
in the upstream notes against this table before repeating it in ours.

## Workflow

### 1. Orient

Read the pin **from `pyproject.toml`**, not from the virtualenv:

```bash
grep -n '"mthds' pyproject.toml
.venv/bin/python -c "import importlib.metadata as m; print(m.version('mthds'))"
```

Under an exact pin these two should agree, in both directions — unlike a floor,
where a venv running ahead was normal. Any disagreement means the venv is stale:
someone edited `pyproject.toml` without re-running `make li`, or installed
something over it. Re-sync with `make li` before you measure anything against
the venv.

Check `git status` and note what was already dirty **before** you start.
Concurrent work in this worktree is normal, and at the end you need to separate
your changes from theirs and never stage something that isn't yours.

Then ask the ledger what it already knows. `mthds-python` files items here when
it lands something this engine will have to absorb, and those items usually
carry the exact diff — file, line, and the shape of the fix — which is faster
and more reliable than rediscovering it from a pyright error:

```bash
ledger inbound
ledger list --origin mthds-python --status open
```

The second query is the targeted one — every item `mthds-python` filed, wherever
it landed — and it is worth reading past the rows owned by this repo, because a
row owned by `pipelex-sdk-python` or by `mthds` is a piece of the same cascade
you will be filing into at step 10.

An item that describes the adaptation you are about to do should be claimed
(`ledger claim <id>`) before you start.

### 2. Resolve the target version

If the user named a version, use it. Otherwise ask PyPI:

```bash
curl -s https://pypi.org/pypi/mthds/json \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['info']['version'])"
```

`info.version` is the latest non-prerelease, which is what "latest" means for a
pin other people inherit exactly.

**Ask PyPI, never the sibling checkout.** `mthds-python/pyproject.toml` is a
working tree and is frequentl