[Bug]: Project favicon lookup probes ~30 paths one at a time, so a slow disk stalls assets.createUrl for a minute #12542

Area

apps/server

Steps to reproduce

1. Run the server on a host where filesystem calls are slow (in my case a WSL2 host under heavy memory and I/O pressure, where one stat took 1 to 4 seconds).
2. Open a client so that it requests project favicon asset URLs (assets.createUrl).

Expected behavior

A favicon lookup costs about one filesystem round trip, because the probes do not depend on each other.

Actual behavior

ProjectFaviconResolver.resolvePathUncached probes 21 well-known paths and then 7 source files one after the other. A miss costs about 30 sequential filesystem calls, so the request time is 30 times the latency of one call. The cache added in #9080 does not help a cold lookup, and a miss stays cached for only 1 minute.

Numbers from server.trace.ndjson during the slow period:

One slow call, by child span:

ws.rpc.assets.createUrl                          77697 ms
  AssetAccess.issueAssetUrl                      77648 ms
    WorkspacePaths.normalizeWorkspaceRoot         1241 ms
    ProjectFaviconResolver.resolvePath           60149 ms
      ProjectFaviconResolver.resolvePathUncached 60140 ms
        findExistingFile  1942 ms
        findExistingFile  1781 ms
        findExistingFile  2274 ms
        findExistingFile  4420 ms
        ... (one span for each candidate, in sequence)
    ServerSecretStore.getOrCreateRandom           1435 ms

Impact

On a slow disk or a loaded host, project icons and every other assets.createUrl call for a project favicon wait for a minute or more. The host was the root cause of the slowness in my case, but the sequential walk multiplied it by 30.

Version or commit

0.0.43-nightly.20260918.1895. The code is the same on main at 0f1b572.

Environment

Linux (WSL2), server run as a service.

Workaround

None. A proposed fix probes the candidates concurrently and keeps the priority order.