Multi-project ty.toml support: one LanguageClient per project

[mattparks]

Summary

Disclaimer: This PR was developed with assistance from Claude Opus 4.6. I'm opening this because the multi-project support has been extremely useful for my monorepo workflow, but I'm fully open to reworking the approach based on the project's long-term plans for monorepo/multi-project support.

Adds multi-project support for monorepos with multiple ty.toml files.

The ty server creates one project per workspace and resolves extra-paths relative to the workspace root, not the config file directory. In
monorepos where subdirectories each have their own ty.toml with project-specific extra-paths, this means paths resolve incorrectly and only one
project can be active at a time.

This PR starts a separate LanguageClient per discovered ty.toml, each scoped to its project subtree via documentSelector. To work around the
path resolution issue, a temporary copy of each ty.toml is written with absolute paths and passed as configurationFile. A FileSystemWatcher
restarts servers when ty.toml files are created or deleted.

Adds smol-toml as a dependency to parse and rewrite config files with resolved paths.

Ref: astral-sh/ty#693

Test Plan

Tested in a monorepo with three ty.toml files at different directory depths, each with different extra-paths:

• Verified each project starts its own server (visible in "ty: Show Logs" output)
• Opened files from two projects side-by-side; each resolves imports from its own extra-paths
• Confirmed no command 'ty.printDebugInformation' already exists errors (non-primary clients skip ExecuteCommandFeature registration)
• Created a new ty.toml in a fourth directory; FileSystemWatcher detected it and restarted with the new project included
• Deleted a ty.toml; servers restarted without the removed project
• Workspace with no ty.toml files falls back to a single default server
• just check passes (prettier, eslint, tsc)

[BurntSushi]

Hmmm I think this is starting a new language server for every ty.toml? I think we have historically not wanted to do this because it could be quite expensive in terms of memory usage. See astral-sh/ty#1554

[mattparks]

Hmmm I think this is starting a new language server for every ty.toml? I think we have historically not wanted to do this because it could be quite expensive in terms of memory usage. See astral-sh/ty#1554

This makes sense, it looks like there has been an ongoing effort to support mono repos in ty, it looks like the main thread has been under astral-sh/ty#2410

This PR should not merge as is, I still think it was worth sharing as a stop-gap if others need this support now to build tooling on TY while we wait for better support.