vscode: centralise duplicated builder-lookup and file-view config reads #1072

Context

Surfaced during the PIR #1066 review (Builders sidebar / diff navigation). Two repeated inline patterns in packages/vscode were deliberately left untouched to keep that PR scoped; filing here so they can be cleaned up on their own.

1. Builder lookup by id

builders.find(b => b.id === <id>) is repeated across several command and view files:

• commands/open-worktree-window.ts
• commands/run-worktree-dev.ts
• commands/open-worktree-folder.ts
• commands/view-artifact.ts
• commands/view-diff.ts
• commands/diff-nav.ts
• views/builders.ts (now via a local builderWithWorktree helper added in vscode: sync Builders sidebar selection with the active builder-diff file #1066)

Proposal: a single shared builderById(overviewData, id) helper (and/or a builderWithWorktree variant that narrows worktreePath to a non-null string, mirroring the one #1066 introduced in views/builders.ts). Callers keep their own not-found handling.

2. File-view-as-tree config read

getConfiguration('codev').get<boolean>('buildersFileViewAsTree', true) is now read in three places with the same key + default:

• views/builders.ts (viewAsTree())
• extension.ts (readFileViewAsTree())
• commands/diff-nav.ts (viewAsTree(), added in vscode: sync Builders sidebar selection with the active builder-diff file #1066)

Proposal: a single typed reader so the key and default live in one place.

Note: this package currently has no central config-helpers module by design (roughly ten files read getConfiguration('codev') inline). Centralising even one key sets a small precedent, so this is a judgement call rather than an obvious win. Scope to just the file-view key, or fold into a broader settings-reader module, as the maintainer prefers.

Out of scope

• Behavior changes. This is a pure refactor: same lookups, same config values, fewer copies.
• The broader question of whether all ~10 inline getConfiguration('codev') reads should move behind a settings module (decide that separately if the file-view reader lands well).