The live test after the faster walk still took 2.9-5.2 s for the first
Images open after a restart. py-spy showed the walk was now small; the time
went to the workspace's own caches, cold after a restart and built by three
parallel first requests at once: the favorites listing (Path.relative_to per
file), the per-file values and newest order, and the prompt-link read.
- Once the host's startup warm-up has run, a stored walk that changed a
listing schedules one executor job that builds what a first page reads,
through the request path itself (_select_workspace_page with the default
filters, then _workspace_favorite_paths). A walk stored during a build
asks for one more build; an unchanged walk (same list kept) builds
nothing; a failed build only warns; on_cleanup stops it. Servers that
never ran the warm-up (the test servers) start no build.
- _favorite_listing slices the path strings as _listed does, falling back
to relative_to for a path outside the root string.