feat: support uses blocks locally

[uinstinct]

Description

Add support for having local uses block in config.yaml defined with file://path/to/file

resolves CON-3869
closes #5943
closes #6107

AI Code Review

• Team members only: AI review runs automatically when PR is opened or marked ready for review
• Team members can also trigger a review by commenting @continue-general-review or @continue-detailed-review

Checklist

• [] I've read the contributing guide
• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screen recording or screenshot

feat.mp4

Tests

[ What tests were added or updated to ensure the changes work as expected? ]

---

Summary by cubic

Support local file includes in config.yaml via file:// uses blocks, so assistants can load models, MCP servers, prompts, and rules from nearby files. Addresses CON-3869; closes #5943 and #6107.

• New Features
  • Unrolls file:// uses in models, mcpServers, prompts, and rules during config load, including overrideConfigYaml.
  • Resolves local URIs with localPathOrUriToPath and derives registry root from the config file directory.
  • Adds a test that loads a rule from a local block to verify end-to-end resolution.

[uinstinct]

@RomneyDa currently this implementation makes all uses blocks in the config relative when a uses: file://path/to/file is present. Do we want to support a combination of uses: package-name/block-name and uses: file://path/to/file?
In that case, we might need to change how slugs currently work

[RomneyDa]

@uinstinct yes, it should support both

[ShaunaGordon]

What I'd personally really love is slugified local references (like uses: models/model.yml), that automatically pulls from the relevant folder within ~/.continue (that's honestly what I'd thought it'd do when I was first learning about how to import stuff in Continue), but that's at best a ways off, with the current global import nature of those folders, unless we can add a folder like "imports" or something that doesn't get auto-imported and use that as the import root, but that feels a little clunky.

Alternatively, relative paths with ~/.continue as the root would be super nice, too, which would allow users to create our own "imports" folder or something (assuming the global import mechanism limits its scope to the specific folders) and sort of simulate the slugification, just with an extra segment, and if a structure is defined, could be easy enough to separate from Hub slugs, by virtue of having three segments instead of two (e.g. uses: local/models/model.yml), or, absent a defined structure, a quick look in the local ~/.continue/workspace/.continue for the presence of the top level segment and fall back to Hub in its absence.

(It's possible the above is out of scope, and if so, the current behavior in this PR can be worked into something similar, albeit a bit clunkier and more fragile, but it's definitely a solid start. 👍🏼 )

[RomneyDa]

@uinstinct let's find an approach that allows using hub slugs in the same assistant. I think you can handle it at the registry level

[RomneyDa]

I believe all this type checking should be unnecessary since we use zod to load the YAML. Might requires some nullable checks but otherwise should be typesafe

[RomneyDa]

remove any type casting

[RomneyDa]

no any types needed

[RomneyDa]

@ShaunaGordon I think we could easily add the relative path from ~/.continue relative folder if ends in .yml/.yaml!

[RomneyDa]

Closing in favor of #7723