chore(release): @hasna/repos v0.1.40

[andrei-hasna]

Cuts @hasna/repos 0.1.40. Version bump plus changelog only — no source change.

Why this release matters more than a routine bump

0.1.39 predates both bare-name resolver fixes. Measured, not assumed:

git grep -c "_factory_src" v0.1.39 -- src/db/repos.ts   ->  rc=1 (absent)
git grep -c "_factory_src" afb0e420 -- src/db/repos.ts   ->  6

and the installed 0.1.39 bundle agrees — _factory_src appears in 0 of 5
shipped dist/*.js files, while positive controls (AmbiguousRepoName,
worktrees) each match 4 of 5 and a runtime-built sentinel matches 0.

So on 0.1.39 the defect is live. Against the real registry:

repos repo repos --json
  "path": "/home/hasna/workspace/hasna/opensource/_factory_src/repos"
  "default_branch": "fix/rungs-provenance-io-guard"

A worktree cut from that is a day stale and on the wrong branch. 0.1.40 is the
first release in which that stops.

Behavioural verification of all four #60 sites

Not a symbol grep — isDerivedCheckoutPath already had 20 hits before #60 and
the merge does not even touch src/db/repos.ts. Instead the same harness ran
against a 200 MB snapshot of the live registry (sqlite .backup, so WAL-consistent)
under HASNA_REPOS_REQUIRE_EXPLICIT_DB_PATH=1, with a sentinel row present only
in the copy to prove isolation held rather than assuming the env var was honoured.

site	v0.1.39	main afb0e420
ops-producers.resolveRepoPath	/…/_factory_src/zzmirroronly	refuses
db/repos.getRepo	/…/_factory_src/zzmirroronly	null
graph.queryRelated	bound to mirror id	[]
graph.getDeps	bound to mirror id	[]

FAILURES=6 before, FAILURES=0 after. Both arms reachable, so the harness can
fail and can pass.

Over-breadth control — a filter that excluded everything would also pass a
naive test. A name with no mirror (zzcanon) still resolves and still binds
graph edges in both arms; where a derived and non-derived row share a name
(zzboth), the canonical one wins. So the filter narrowed the defect and nothing else.

Parenthesisation — checked explicitly, since AND binds tighter than OR.
resolveRepoPath is the only site with a multi-branch predicate and it wraps
correctly: WHERE (name = ? OR path = ? OR (org || '/' || name) = ?) AND (…).
The other three are single-equality, so precedence never applied.

What I did NOT check

• graph.ts:120, the dependency-edge builder, is exercised only through its
  shared nonDerivedCheckoutSql helper and the PR's own tests — not through a
  full buildGraph() run, which would have needed on-disk package.json scans.
• No individual claim inside fix(registry): close the remaining bare-name-to-scratch-clone resolvers #60's own added tests was re-derived; they are
  established to pass, not audited.

Pre-existing, non-blocking

src/cli/docs-parity.test.ts times out at its 30000 ms budget. It reports
30030.90ms — the budget firing, so the true runtime is unbounded and this is
no result rather than a failure. It reproduces identically on tag v0.1.39,
so it is not a regression from #60; station01 was at load 13.4. CI runs the same
test on an unloaded runner and passed 8/8 at v0.1.39. Suite otherwise
781 pass, typecheck clean.

Agent: Silvanus

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}