Haft 9.0.1

A patch release for one defect. Its published predecessor is
v9.0.0. No contract,
capability, or authority boundary changes in this release.

The defect

v9.0.0 introduced the canonical project-relative path invariant for
affected_files and enforced it on both the write and the read path, but
shipped no migration for rows admitted before that invariant existed.

A project database carrying even one absolute or traversing path — for example
an agent attachment recorded as an affected file — failed every
concern-seeded explore call:

fuse concern reasoning: stored affected file for <artifact-id>:
affected file: path "<absolute path>" must be a canonical project-relative path

Symbol-seeded explore was unaffected, which is why the failure read as
intermittent rather than as a whole surface being down. The root cause is not a
wrong path rule and not a corrupt database: it is a strict read-side invariant
introduced without a paired migration, combined with a read that failed the
entire projection on the first row it could not express.

Fresh installations were never affected. Both write paths have canonicalized
since v9.0.0, so only databases that predate the invariant carry such rows.

What changed

AllAffectedFiles and GetAffectedFiles now exclude a row the current path
invariant cannot express instead of failing the read. The projection returns
the expressible rows together with a named Skipped entry per excluded row, so
the gap stays visible as data rather than disappearing into a silently narrower
graph. Concern fusion reports the count as unexpressible_affected_files in
its basis.

Kernel migration 58 drops the rows that cannot be expressed. The invariant
belongs to internal/projectpath, so the migration asks that package rather
than restating the rule in SQL, verifies that no such row survives, and names
every dropped row and artifact instead of deleting silently.

The two repairs are independent on purpose: the read fix restores explore
even where the migration has not run yet, and the migration makes the stored
table agree with what every reader can express.

Upgrade from v9.0.0

Install the new binary, then run haft init once in each existing project:

haft init            # applies kernel migration 58

Migration 58 applies during haft init. haft serve and the read-only
surfaces require an already-current schema and report kernel schema is not current until that one command has run. Restart any host session afterwards so
every MCP process loads the same binary.

A database that never carried a pre-invariant row pays nothing and reports
nothing. This release adds no schema objects and removes no capability.

This committed note describes the release contract; it does not record a P13 or
P14 result and is not release authority. Tag validation and public GitHub
Release publication are separate operator-controlled actions.