[ty] Move script environment initialization to the CLI and LSP

[MichaReiser]

Summary

This PR moves from a lazy PEP 723 script discovery do eagerly discover all scripts as part of the project's file discovery.

There are two motivations for doing this:

1. Initializing the script's environment before checking the script is not sufficient. Other files can import the script, and type inference can then resolve file_settings and python_version_with_source which are both environment dependent (the former less so, but uv can tell us the python version). Initializing all scripts before we start checking ensures that type inference sees the right environment even when a script has been imported. This is the bug that Zsolt identified in my initial PEP 723 PR.
2. Today, the LSP only initialized scripts when the user opened them. However, that means that their environment isn't available as part of find references and workspace symbols. This can result in missed references (note, making find references return all project and script references when searching for references of a shared dependency requires a few changes to find references as well, but this sets the foundation for it). Initializing all environments when opening the project ensures the environments are available when running find references (or the user can rerun find references once all syncs are complete, but they don't have to open every script just to make sure that find references will show the references in them)
3. Knowing all scripts simplifies file watching because we now have distinct points where script environments can change, and may require updating the watched paths.

Now, there are a few downsides as well, but I think this is the right trade off (honestly, I don't know how to fix 1 easily without it, and 3 was the main reason why I considered this approach even before Zsolt found the bug).

• Unlike before, the LSP now indexes and reads all project files. This can mean that startup now takes a second or so on very large projects where it was instant before, because we didn't do any form of indexing. This also means that the LSP retains more memory for projects that don't use workspace diagnostics (or find references), because the LSP now loads all files into memory to determine whether a file is a script. This is inherent to the approach. I suspect that we can mitigate the "all source in memory" in the future by only storing compressed source text, which should reduce memory usage by about 70%.
• We now sync all scripts on LSP startup. I could see this become a problem in workspaces with many (with 100 or 1000s scripts). If this becomes a problem, I think we can a) limit script sync to on-open, accepting that find-references etc. may require opening the relevant scripts and/or b) allow users to selectively sync scripts by using a LSP command. For now, I think syncing all scripts should be fine, given that uv is fast (the first time might take a while)
• I had to make the uv sync queue unbounded. It's still bounded by the number of scripts and projects. But we no longer apply back pressure if the sync requests start piling up. The reason I had to remove it is because we don't want a didChange or didOpen to block, only because there are already 8 queued scripts. But more importantly, we don't want to block the LSP startup until all scripts have synchronized, but queuing them up during startup would just have done that (because the main loop blocks everytime time the queue is full). I think this is okay, and I'll add another PR on top of this one that adds cancellation support for sync requests. I also think that our previous back pressure wasn't as impactful as I thought
• We now sync scripts before checking the files. That means, ty no longer makes progress on checking other project files while the syncs are pending. This is the one I'm the most bumped about. It was so cool that ty often checked the entire project while waiting on uv to finish syncing. To mitigate, I increased the worker pool to N/4 where N is max parallelism and, while testing, I also found that syncinc all scripts, at least in Ruff's repo, is instant once uv is warm.

I think this also gets us into a position where adding support for nested projects becomes much easier, because they'll naturally fit in. We'll discover nested projects as part of indexing Files (we'd need to move that off Project), synchronizing their environments can happen at the exactly same points as synchronizing scripts. The biggest remaining lift is to change ty_project and ProjectDatabase to no longer assume that there's a single Project (but there is still one main project).

Test Plan

CLI

Screen.Recording.2026-08-27.at.16.29.49.mov

Screen.Recording.2026-08-27.at.16.36.21.mov

[astral-sh-bot]

Typing conformance results

No changes detected ✅

Current numbers

The percentage of diagnostics emitted that were expected errors held steady at 97.69%. The percentage of expected errors that received a diagnostic held steady at 93.71%. The number of fully passing files held steady at 110/136.

[astral-sh-bot]

Memory usage report

Memory usage unchanged ✅

[astral-sh-bot]

ecosystem-analyzer results

No diagnostic changes detected ✅

Large timing changes:

Project	Old Time	New Time	Change
dd-trace-py	2.91s	1.20s	-59%

Flaky changes detected. This PR summary excludes flaky changes; see the HTML report for details.

Full report with detailed diff (timing results)

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[codspeed-hq]

Performance comparison unavailable

The base and head of this comparison were measured with different runner settings, so their benchmark values are not directly comparable.

What changed between base and head:

• Cycle estimation (off → on) changes how benchmark performance is calculated. Learn more about cycle estimation

Re-run the base with the same settings to get a valid performance comparison.

---

_{Comparing micha/ty-script-preparation-watching (94b0ebf) with micha/uv-project-sync-service (e01c4ed)}

[MichaReiser]

This is sort of an unrelated fix. Previously, we always added a script to the known project files even when exclude_scripts was on, which was wrong. We now respect the exclude_scripts setting

[MichaReiser]

We now create a single progress indicator to sync scripts. This is important now, because VS Code otherwise shows one progress bar per script, which could get annoying real quick in a workspace with many scripts