feat: per-repository settingSources override

[yscivideo]

What

Adds repositoryConfig.settingSources so a self-hosted multi-repo setup can opt a specific repository out of the Claude Agent SDK's default ["user", "project", "local"] setting sources.

Why

When one Cyrus install serves several repositories, every session inherits the operator's global ~/.claude user-scope surface — skills, slash commands, agents, plugin MCP servers. For a repo that ships its own project-scope .claude/ config, that inherited surface is dead weight in every session's context (in our install: 133 slash commands → 35, 104 skills → 15 after opting the repo down to ["project", "local"]).

How

• New optional settingSources field on RepositoryConfig (JSON schema + types), validated by a shared isValidSettingSourcesOverride helper in cyrus-core: must be a non-empty array of "user"/"project"/"local".
• Threaded through RunnerConfigBuilder (Claude runner only) and the prewarm path in EdgeWorker, mirroring the existing repository.model / repository.fallbackModel precedence pattern.
• Unset or invalid override falls back to the stock default — behavior is unchanged unless a repo opts in.

Testing

• 11 new tests (ClaudeRunner, RunnerConfigBuilder, core validator); full monorepo build + pnpm test:packages:run green.
• Running in production on our self-hosted install as a local dist patch; upstreaming as a proper config-schema feature.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QUrjDzWxhuTbN53VT9a13K

[Connoropolous]

Hi @yscivideo

Which company are you running Cyrus at that you ran into this?

Thanks for contributing, I've taken a quick look at the code.

[yscivideo]

Thanks for taking a look. It's a self-hosted install driving an educational-content pipeline out of a single Linear workspace. The operator account on that machine has a large user-scope ~/.claude — 133 slash commands and 104 skills, mostly unrelated to this repo — and every session inherited all of it even though the repo ships its own .claude/ config with the ~15 skills it needs. Opting it down to ["project", "local"] cut that to 35 commands / 15 skills. I'd expect it anywhere one install serves several repos and the operator account carries its own user-scope config. Happy to adjust anything in the implementation.