Handling Multiple Publicodes Models per Workspace

[OleksandraKordonets]

Fixes #24

Currently the server assumes that all .publicodes files belong to the same model. In monorepos and multi folder workspaces this causes rules from unrelated packages to be mixed, so references can resolve across projects that should be isolated. By introducing explicit model boundaries and routing requests per model, the language server better matches real workspace layouts, avoids confusing cross model resolutions, and scales to monorepos without forcing users to split their workspace.

This change teaches the Publicodes language server to handle multiple independent models in a single workspace. Instead of merging every .publicodes* file into one global engine, the server now groups files by a model boundary, closest .publicodes.config.{ts,js} or package.json, and builds separate rule indexes and engines per model. All language features then resolve through the model that owns the current file, so rules from different packages no longer bleed into each other.

Implementation wise, the server now tracks a small registry of models keyed by their root, maps each file to its model, and updates parsing, validation, hover, completion and definition flows to always look up rules through the owning model. Boundary detection walks up from a file to find the nearest .publicodes.config.{ts,js} or package.json, and file add, change and delete events keep each model's rule index and diagnostics in sync with the workspace.

[EmileRolley]

Hi @OleksandraKordonets,

Thanks for the contribution! I'll review your work as soon as I find a moment.