[Bug]: Workspace index scan timeout of 15s is hardcoded and fails the whole Files panel with no partial result

What happened

On a large workspace the Files panel is permanently unusable. Every attempt shows:

Failed to list workspace entries in 'D:\Workspace'.

The surfaced message does not name the cause. The real cause is only visible in
~/.t3/userdata/logs/server.trace.ndjson, nested inside exit.cause:

ProjectListEntriesError: Failed to list workspace entries in 'D:\Workspace'.
  [cause]: WorkspaceSearchIndexScanTimedOut: Workspace search index for
           'D:\Workspace' did not finish scanning within 15 seconds

Why this is a hard wall rather than a slow path

WORKSPACE_INDEX_SCAN_TIMEOUT_MS is 15000 and is compiled in. There is no setting in
Settings, in settings.json or in client-settings.json that changes it. When the scan
exceeds it, waitForIndexReady fails and the whole projects.listEntries call fails.
No partial listing is returned, so the panel shows nothing at all.

WORKSPACE_INDEX_IDLE_TTL is 15 minutes, so the index is dropped while idle and the
failure repeats on every later use. There is no state in which the panel recovers.

A fixed wall-clock budget for an operation whose cost varies tenfold

Two durations of WorkspaceSearchIndex.waitForIndexReady from the rotated trace logs,
same machine, same workspace, nothing changed in between on my side:

Date	Duration	Outcome
2026-09-08	10232 ms	scan completed, panel worked
2026-09-09	15028 ms	deadline hit, panel dead

I cannot tell you why the second one was slower, and that is the point. To find out, I
timed an equivalent directory walk over the same tree in two cache states:

Walk	Files	Duration
Cold OS metadata cache	146377	100.8 s
Warm OS metadata cache	146377	9.9 s
Warm, with build and VCS directories excluded	93482	3.2 s

The operating system's directory-metadata cache is worth about a factor of ten here.
Cutting the tree by 36 % is worth about a factor of three. So a fixed 15-second budget is
being applied to work whose real cost swings by an order of magnitude for reasons that
have nothing to do with the workspace: a reboot, memory pressure, another process
evicting the cache, a slower disk.

That makes the failure intermittent rather than deterministic, which is far harder to
diagnose than a clean size limit. It also means every large workspace is at its most
fragile right after a reboot, exactly when a user is most likely to open the app.

For scale, the tree the indexer actually walks:

Level	Files
Total in tree	655098
Under node_modules (already excluded by T3)	478681
Effectively scanned	146377

I deliberately quote no files-per-second figure for T3 itself. The 15028 ms scan never
finished, so its rate is unknown, and the cache measurements above show that any such
figure is meaningless without stating the cache state it was taken in.

Environment

• T3 Code 0.0.40 (Alpha), installed via winget install T3Tools.T3Code
• Windows 10 Home 19045, workspace on a local NTFS drive
• Workspace is not a git repository; it is a Subversion working copy
• Reinstalling does not help, since nothing about the install is at fault

Suggested fixes, in order of preference

1. Return whatever the scan has found when the deadline passes, and mark the listing as
   incomplete, instead of failing the entire call. A truncated file tree is far more
   useful than an error string.
2. Make the timeout configurable per project or globally.
3. Keep a successful index across the idle TTL for workspaces whose scan is known to be
   slow, so the cost is paid once rather than every 15 minutes.

Related to #4640, which reports the sibling problem of silent truncation at 25,000
entries. Both come down to the same thing: large workspaces have no supported path.

Start by tracing WorkspaceSearchIndex.waitForIndexReady and the projects.listEntries call, then inspect the WORKSPACE_INDEX_SCAN_TIMEOUT_MS and WORKSPACE_INDEX_IDLE_TTL definitions. Compare the existing failure path with the requested partial-result, configurable-timeout, and index-retention options. Done means the Files panel remains useful for scans exceeding 15 seconds and the behavior is covered for large workspaces.