Attribute a clip by the text it handed Obsidian

[mlsimon734]

Summary

tab_clip accepts a vault override, and until now nothing could tell a caller that the name was wrong. The handoff is an obsidian:// URL given to the OS: an unrecognised vault fails inside Obsidian, where neither end of the bridge can observe it, and the call still reports success.

Gullet now checks an explicit vault name against Obsidian's local obsidian.json registry before forwarding it. A readable, understood registry that does not contain the name produces a bad-request listing the vaults that registry knows.

Deliberately a soft check

The registry is undocumented and incomplete, and its location varies outside a standard install. So absent, unreadable, malformed, unfamiliar, or empty (vaults: {}) all preserve the old pass-through behavior — only a registry that positively contradicts the name refuses the call. An empty registry proves nothing about a name the user read off their own vault switcher, so it belongs with the other soft cases rather than producing a rejection listing "(none)".

The error describes known vaults rather than claiming to enumerate every vault on disk. The extension still cannot validate the destination.

Parsed contents are cached by modification time and size (one stat() per call), so a vault added while Gullet is running appears on the next changed-file check.

Notes

• knownObsidianVaults is optional on ToolContext, matching rivalHubs? — it can refuse a call it can prove wrong, but an absent lookup never changes one, so construction sites need no stub.
• parseVaultOverride is exported so the vault check reads only the vault field. It previously ran the whole parseTabClipParams, meaning Gullet re-validated tabId and close — which the extension owns — and reported those errors from a function named for the vault.
• The existing vaultWarningFor path-vs-name check is unchanged.

Verification

bun run typecheck, bun test (398 pass), bun run format:check, bun run lint:js.

No manifest or permission changes. No UI changes.

---

Live verification (added after opening)

Done against a plain Firefox 134 carrying this build, attached to the same hub as my
real Zen — the hub serves both connections at once, so nothing about my session was
disturbed. The verifier ran in freshly spawned Gullet processes built from this branch.

1. The hash survives the round trip. Clipped a Wikipedia article; the extension
   reported contentHash: cb7e769…, and re-hashing the file Obsidian wrote gave the
   same digest. That is WebCrypto in the browser agreeing with Bun.CryptoHasher on the
   filesystem, through the OS clipboard and the obsidian:// handoff — the one link the
   unit tests cannot reach.
2. A wrong hash is refused, against the real note on disk. Same file, same reader
   code, only the expected digest altered: landed → mismatched. With no evidence at
   all the same note still verifies landed, which is the pre-hash behaviour and shows
   the hash is what does the discriminating.
3. The residual scenario itself. Two separate Gullet processes clipping two tabs of
   the same URL simultaneously: both landed, on distinct notes, and each reported
   hash matched a different file (21f2810f… → Crocodile 2.md, f1746a68… →
   Crocodile 3.md). Before this branch there was nothing to tell those two apart.

Incidentally: two processes clipping the same tab at once left one clip fine and the
other extract-failed — the same family as #20, and not something this branch changes.

---

Also carries a one-line .gitignore fix: dev browser profiles were ignored three-by-name, so the .dev-profile-live this testing created was untracked but not ignored — and those profiles hold the bridge token in extension storage. Now .dev-profile*/.