#1915 swamp extension quality resolves datastores: against the repo root but models: against the manifest dir — datastore extensions are unscorable in a monorepo

Summary

swamp extension quality <manifest> --json resolves a manifest's datastores: entries against the repository root, but models: entries against the manifest's own directory. When an extension is vendored into a monorepo (i.e. the extension directory is not the repo root), every datastore extension becomes unscorable.

Reproduce

In a swamp repo whose root holds several extension subdirectories (a .swamp.yaml at the workspace root), with a datastore extension vendored at swamp-mongodb-datastore/:

$ swamp extension quality "$PWD/swamp-mongodb-datastore/manifest.yaml" --json
{
  "error": "Datastore file not found: mongodb/mod.ts (expected at /.../swamp-workspace/extensions/datastores/mongodb/mod.ts)"
}

The manifest declares:

datastores:
  - mongodb/mod.ts

and the file really is at swamp-mongodb-datastore/extensions/datastores/mongodb/mod.ts.

A model extension in the SAME repo, invoked the same way, scores fine:

$ swamp extension quality "$PWD/telegram-send/manifest.yaml" --json
{ "status": "passed", "rubricVersion": 3, "earnedPoints": 12, ... }

with

models:
  - extensions/models/telegram_send.ts

The inconsistency

In a standalone single-extension repo the two coincide, so this never shows. Vendored into a monorepo they diverge and the datastore file can never be found.

Writing the full path does not help

Changing the manifest to the model-style full relative path makes it worse — the extensions/datastores/ prefix is applied on top of whatever is written:

datastores:
  - extensions/datastores/mongodb/mod.ts

"error": "Datastore file not found: extensions/datastores/mongodb/mod.ts
 (expected at /.../swamp-workspace/extensions/datastores/extensions/datastores/mongodb/mod.ts)"

So there is no manifest spelling that works in a monorepo; the entry is unreachable either way.

Impact

This is not just a bad error message — it fails a CI gate with no available workaround. scripts/quality/score_ratchet.ts classifies a failed score read as unscorable, which is a deliberate hard failure (its docblock explains that this case used to be a silent skip and let a broken extension read as a pass for weeks). So a monorepo containing any datastore extension with a quality.yaml cannot get a green compliance job, and the standard offers no na/backlog escape for it.

Encountered on a real PR: every other quality gate (compliance, allowlist, soak, soak-parity, property harness, upgrade chains) passes and reports all 54 extensions compliant; only the ratchet fails, purely on this path resolution.

Expected

datastores: entries resolve against the manifest's directory, the same as models: — i.e. <manifestDir>/extensions/datastores/<entry> — so a datastore extension is scorable wherever it is checked out.

Environment

• swamp 20260827.012103.0-sha.89734f5f
• macOS arm64, and reproduced identically on ubuntu-latest in GitHub Actions
• Extension under test is a datastore-only package (datastores: key, no models:)