Workspace command and skill menus never refresh once cached #41

What happens

The first time a client asks for a provider's commands and skills in a workspace, ProviderRegistry.refreshWorkspaceSnapshot calls the driver's snapshotForCwd and caches the result on the provider. Every later request for that cwd short-circuits, because the guard treats "an entry exists" as "the entry is current":

https://github.com/Fryuni/t3code/blob/main/apps/server/src/provider/Layers/ProviderRegistry.ts#L812-L818

Nothing invalidates it. A registry refresh preserves the cached entries rather than dropping them (ProviderRegistry.ts:212-215), so the only ways a workspace's menu changes are a live session reporting a new list mid-thread, or a server restart.

So: add a skill on disk, open a new thread's composer, and the new skill is missing from the $ menu — which is exactly the case #39 set out to serve, commands and skills available before the first turn. Removing or disabling one leaves it offerable instead.

Scope

This is registry-level and applies to every driver implementing snapshotForCwd — Claude, Codex, Cursor, Antigravity, Grok, OpenCode, and now OhMyPi. It predates #39; OhMyPi simply made the stale window visible, since for that provider a probe is the only way the list is ever read outside a session.

Worth deciding

Refresh cost is not uniform. Claude, Cursor, and Antigravity rescan directories; OhMyPi spawns an omp acp process per probe (ADR 0006), so "re-probe on every composer open" is not free there.

Options, roughly cheapest first:

• Treat the cached entry as fresh for a short window (a real recorded-at timestamp, not the provider-level checkedAt the OhMyPi driver currently copies) and re-probe past it.
• Invalidate on a signal — a workspace file watcher over the skill directories, or an explicit refresh when a thread starts.
• Expose a manual refresh in the menu, which is cheap but puts the problem on the user.

Found by Codex while reviewing #39.