fix: correct the VSCodium shared storage path

[noctuum]

Summary

DatabaseFilePath.codiumShared points at ~/.vscodium-shared/sharedStorage/state.vscdb.
No VS Code build produces that directory. VSCodium's shared storage lives in
~/.vscode-oss-shared/sharedStorage/state.vscdb.

Because the path never exists, resolve() falls through to the legacy
~/.config/VSCodium/User/globalStorage/state.vscdb, which VS Code 1.118 has already
migrated away from. The runner starts, registers on D-Bus and answers Match() normally —
it just never finds anything. PR #26 fixed issue #25 for Stable and Insiders, but is a
no-op for VSCodium.

Symptom

$ busctl --user call codes.merritt.vscode_runner /vscode_runner org.kde.krunner1 Match s "test"
a(sssida{sv}) 0

vscode_runner: INFO │ 💡 Opened VSCode database file at $HOME/.config/VSCodium/User/globalStorage/state.vscdb
vscode_runner: INFO │ 💡 No recent workspaces found in VSCode database.
vscode_runner: INFO │ 💡 Found 0 matches for VSCodeVersion.codium.

The key is genuinely gone from the legacy database — only a migration breadcrumb is left,
while the live data sits at the sharedDataFolderName location:

$ sqlite3 ~/.config/VSCodium/User/globalStorage/state.vscdb \
    "SELECT count(*) FROM ItemTable WHERE key='history.recentlyOpenedPathsList';"
0

$ sqlite3 ~/.vscode-oss-shared/sharedStorage/state.vscdb \
    "SELECT length(value) FROM ItemTable WHERE key='history.recentlyOpenedPathsList';"
1878

$ ls -d ~/.*-shared
/home/user/.vscode-oss-shared        <-- the only one that exists

Reproduction

1. VSCodium >= 1.118, open a few folders to populate the recent list.
2. vscode-runner v1.9.2 installed.
3. busctl --user call codes.merritt.vscode_runner /vscode_runner org.kde.krunner1 Match s "<project>"
   -> a(sssida{sv}) 0.
4. sqlite3 ~/.vscode-oss-shared/sharedStorage/state.vscdb "SELECT length(value) FROM ItemTable WHERE key='history.recentlyOpenedPathsList';"
   -> non-zero, proving the data exists.

What VS Code actually reads

The directory name is not dataFolderName with a -shared suffix. It comes from a
separate product.json key, sharedDataFolderName:

// storageMainService.ts
const sharedStorageFolderPath = join(
  this.environmentService.appSharedDataHome.with({ scheme: Schemas.file }).fsPath,
  'sharedStorage'
);

// environmentService.ts
get appSharedDataHome(): URI {
	// ... --shared-data-dir and VSCODE_PORTABLE overrides ...
	return joinPath(this.userHome, this.productService.sharedDataFolderName);
}

sharedDataFolderName is a required field on the product definition, declared next to but
independent of dataFolderName. Permalinks pinned to microsoft/vscode@849be60e:
environmentService.ts#L150-L163,
storageMainService.ts#L203,
product.ts#L120-L121.

The suffix rule is an easy assumption to make, and it is documented that way upstream:
microsoft/vscode#311317, the PR that
introduced this storage, describes the location as
~/<dataFolderName>-shared/sharedStorage/state.vscdb. That description holds for
Microsoft's own builds, where sharedDataFolderName does equal dataFolderName +
-shared. It does not hold for rebranded forks.

Folder names per build

Build	dataFolderName	sharedDataFolderName	Source for the shared name
Code - OSS	.vscode-oss	.vscode-oss-shared	product.json#L6
VSCodium stable	.vscode-oss (not rebranded)	.vscode-oss-shared (inherited)	prepare_vscode.sh#L96-L121 — 26 setpath calls, neither dataFolderName nor sharedDataFolderName among them
VSCodium Insiders	.vscodium-insiders (rebranded)	.vscode-oss-shared (inherited)	prepare_vscode.sh#L68-L94 — 27 setpath calls, including dataFolderName (L71) and serverDataFolderName (L76), but not sharedDataFolderName
VS Code Insiders	.vscode-insiders	.vscode-insiders-shared	product.ts#L121 doc comment
VS Code stable	.vscode	.vscode-shared	<dataFolderName>-shared per the microsoft/vscode#311317 description; Microsoft's branded product.json is generated at build time and is not in the public repo

The VSCodium Insiders row is the one that breaks the suffix rule outright: dataFolderName
is rebranded, sharedDataFolderName is not. prepare_vscode.sh contains zero occurrences
of sharedDataFolderName in the whole file, so both VSCodium qualities inherit the
Code - OSS value and share a single shared-storage directory — there is no separate
Insiders path to add here.

Confirmed against a shipped build:

$ grep -oE '"[a-zA-Z]*[Ff]olderName": "[^"]*"' /opt/vscodium-bin/resources/app/product.json
"dataFolderName": ".vscode-oss"
"sharedDataFolderName": ".vscode-oss-shared"
"serverDataFolderName": ".vscodium-server"

The change

codiumShared now points at .vscode-oss-shared. .vscodium-shared is removed rather
than demoted to a fallback, since no build has ever produced it. Stable and Insiders are
untouched, so the fix from PR #26 cannot regress.

With this applied, DatabaseFilePath.resolve(VSCodeVersion.codium) returns
~/.vscode-oss-shared/sharedStorage/state.vscdb and the runner matches again.

Not covered by this PR

All pre-existing, and all affect every variant rather than just VSCodium:

• --shared-data-dir overrides the directory entirely.
• VSCODE_PORTABLE redirects it to <portable>/shared-data/sharedStorage/state.vscdb
  (note shared-data, not sharedStorage's usual parent).
• Reading sharedDataFolderName from the installed product.json would be correct by
  construction and is what other consumers of this database do — see Raycast's
  visual-studio-code-recent-projects
  and yasb.
  The cost is locating the install directory, which varies across /opt, /usr/share,
  /usr/lib, Flatpak, Snap and AppImage; on Arch the codium entry in PATH is a shell
  wrapper that execs another wrapper, so it cannot be walked to
  resources/app/product.json generically.
• resolve() logs nothing when every candidate misses. A line listing the paths that were
  checked would have made this class of bug diagnosable from a journal paste alone.

Happy to follow up on any of these separately.

Environment

Component	Version
vscode-runner	v1.9.2
VSCodium	1.126.04524 (vscodium-bin, Arch Linux)
Plasma / KRunner	6.7.3, Wayland

Related

• Issue Relevant database location has changed with VSCode 1.118.0 #25 — the original 1.118 report
• PR feat: support new database shared storage locations #26 — the fix that covered Stable and Insiders
• microsoft/PowerToys#47445 /
  microsoft/PowerToys#47505 — the same
  bug in another consumer of this database.