Fix #799: use custom scheme for builder changed-file resourceUri

[amrmelsayed]

Summary

• Switches BuilderFileTreeItem.resourceUri from file: to a custom codev-builder-diff: scheme so VSCode's built-in Git FileDecorationProvider stops firing on these rows and overriding our SCM-style colors with gitDecoration.ignoredResourceForeground (grey).
• Adds a shared builderFileResourceUri(worktreePath, rel) helper used by both BuilderFileTreeItem and BuilderDiffCache.syncDecorations, and switches the decoration map's keying to uri.toString() so the URI fired through onDidChangeFileDecorations matches what the tree row carries.
• Adds 5 regression cases (src/test/builder-file-tree-item.test.ts) covering the scheme, the decoration lookup, and the change event.

Fixes #799.

Why custom scheme

VSCode's IDecorationService is global — every registered FileDecorationProvider is queried for every file: URI rendered anywhere in the editor. For our changed-file rows pointing into gitignored .builders/<id>/…, the built-in Git decorator wins the color merge (it contributes no badge, so ours stays — but its ignoredResourceForeground tint clobbers our status color). Using a non-file: scheme is the canonical workaround: IFileIconTheme keys off basename so the file-type icon still resolves, and Git's decorator only acts on scheme === 'file'.

No TextDocumentContentProvider is registered for the new scheme — these URIs are markers for the tree row only. The diff is opened via the existing codev.openBuilderFileDiff command, which builds explicit left/right URIs and is unaffected by the scheme change.

Test plan

• pnpm exec tsc --noEmit clean
• pnpm lint clean
• pnpm test:unit (vitest) → 34/34 passing
• pnpm test (vscode-test) → 83/83 passing, includes the 5 new cases
• Visual confirmation in a running VSCode session: spawn a builder, expand it in the Builders view, verify Added rows render green / Modified yellow / Deleted red in list-mode and tree-mode

[amrmelsayed]

Architect Integration Review

Single-model integration review (medium-risk PR per triage: 231/17 lines across 5 files, touches shared decoration infrastructure). Claude consult: APPROVE / HIGH confidence.

Verified

• Pattern consistency: matches the existing codev-diff: custom-scheme convention in view-diff.ts
• All downstream consumers traced — codev.openBuilderFileDiff, BuilderFileDecorationProvider.provideFileDecoration, BuilderFolderTreeItem, VS Code's Git decorator, IFileIconTheme — none break
• Shared builderFileResourceUri() helper eliminates URI drift between BuilderFileTreeItem and BuilderDiffCache.syncDecorations (they used different constructors before this PR — real latent bug fixed)
• Keying change fsPath → uri.toString() in the decoration cache is necessary and correct (avoids cross-scheme collision)
• 5 regression tests cover scheme invariant, path preservation, end-to-end construction, cache↔tree consistency, scheme isolation, and onDidChangeDecorations URI fidelity

Cross-cutting note (non-blocking, for #810)

This PR locks in codev-builder-diff: as the file-row scheme. Issue #810 (builder phase+status badges) is planned to introduce a separate scheme (codev-builder: per the issue body) for per-row badge decoration. Two parallel schemes will coexist after #810 lands — that's workable, but worth being intentional.

When #810 reaches spec phase, the spec should explicitly call out the scheme decision: stay with parallel schemes (current direction) or refactor both into a single namespaced scheme (e.g. codev-builder:file/... for file rows, codev-builder:row/... for builder rows). Not a blocker for #867 — just a coordination item for #810's spec author.

Minor observation (non-blocking, optional follow-up)

BuilderFileDecorationProvider.provideFileDecoration doesn't short-circuit on uri.scheme — it queries the cache for every URI VS Code asks about. Adding if (uri.scheme !== BUILDER_FILE_SCHEME) return undefined; would skip the lookup for the vast majority of URIs. O(1) cache lookup means it's cosmetic, but worth a one-liner cleanup at some point.

Unchecked test-plan item

The PR's visual confirmation in a running VS Code session is unchecked. The unit tests cover the URI scheme behavior and the consult validated the system-level impact, so the platform-behavior assumption (VS Code's Git decorator skips non-file: schemes) is well-supported. Will get covered by the next pnpm -w run local-install smoke; not blocking the merge.

Verdict

Approved. Please merge with: gh pr merge 867 --merge --admin (solo-architect workspace can't satisfy self-approval branch protection; see other builders' messages from the same batch).

---

Architect integration review