v0.68.9

The MCP handshake advertised 0.54.0 from a tree that was fully up to date at
0.68.8, and the interface served the same number as `build`.

`__version__` came from `importlib.metadata.version("aihawk")`, which answers
about the distribution the installer put there. For a wheel that is the same
artifact as the code. For `pip install -e` the metadata is written once and the
code keeps moving, and nothing says the two have parted. Pulling does not touch
the record, so this is a defect in the code and not a stale checkout: measured
with the checkout at zero commits behind origin/main.

It was being advertised on the one field built to answer the question.
`mcp/server.py` sets `serverInfo.version` under a comment saying it exists so a
client can correlate a defect with a release, and that handshake had already
been wrong once, carrying the MCP SDK's version for every build of this
package. The remedy then replaced it with a number that is also not ours in the
install mode this project develops and tests in: the CI installs with
`pip install -e ".[test]"`.

A test held it in place, and how it did is the part worth keeping. It asserted
that the string `importlib.metadata` appeared in the source. That is not
"derived, never typed"; it is one particular way of deriving, and it was the
wrong one. A test that pins a mechanism inherits whatever that mechanism gets
wrong. It now asserts the property, over the whole package rather than one
module.

So the version of the code is now: the install record for a normal install,
because the metadata and the code came out of the same build; the version the
source tree declares for an editable one, plus a `+editable` local segment so a
tree that can carry uncommitted work is never read as the published release of
the same number. Which of the two an install is comes from what the installer
wrote (PEP 610 `direct_url.json`), not from a guess about `__file__`.

The record stays, under a name that cannot be mistaken for the version.
`invisible_core` made this same split first, deriving from the seal it ships
and naming the record `__install_record_version__`; this is that decision in
the package that needed it next.

And `aihawk.mcp` no longer runs its own lookup beside the parent's. Two
computations of one fact are free to disagree the day one of them changes,
which is the defect the comment above them was already complaining about.

Verified on the real surface, one variable: the handshake answers 0.54.0 from
the old code and 0.68.8+editable from this one. Six known-bad mutations, six
killed, including the whole previous implementation put back and a wheel arm
that keeps the remedy from consulting a tree that is not what runs.