Add installation-scoped familiar routing and repository policy

[romgenie]

Local source: coven-github/issues/11-add-installation-scoped-routing-and-configuration.md

Summary

Familiar routing should be scoped by GitHub installation and repository policy rather than relying only on a static local TOML list. The current config is appropriate for self-hosted development, but hosted deployments need per-installation routing, trigger, memory, model, and permission policy.

Current Evidence

• crates/config/src/lib.rs defines familiar config with id, display_name, bot_username, model, skills, and trigger_labels.
• crates/webhook/src/routes.rs routes tasks by matching bot username or trigger label from this config.
• DESIGN.md says hosted routing should move to installation-scoped config including installation id, repo, familiar id, allowed trigger labels, memory scope, model/skill policy, and billing tier.
• FAMILIAR-CONTRACT.md says routing and skills should be controlled per installation, repository, and familiar.
• HOSTED.md lists installation/repo scoped familiar routing as a hosted capability.

Problem

Static process-wide familiar config cannot safely represent many customers, installations, repositories, or plans. Trigger labels and bot usernames can collide. Model, memory, and skill choices need to vary by tenant and repository.

Impact

• One installation's label or bot mapping can accidentally affect another installation.
• Hosted customers cannot manage routing without operator config changes.
• Multi-familiar routing and paid plan limits cannot be enforced cleanly.
• Memory policy cannot be tied to the same policy object that routes the task.

Proposed Design

Create an installation-scoped policy model:

• installation id and account identity;
• repository id/name and visibility;
• familiar id and bot username;
• enabled triggers and trigger labels;
• model/provider policy;
• skill/tool policy;
• memory policy;
• publication policy;
• quotas and plan limits.

The webhook router should load policy by installation id and repository id/name before matching labels or mentions. A local self-hosted TOML file can remain as a policy source, but the in-memory representation should be installation-scoped.

Acceptance Criteria

• Routing requires installation scope.
• The same label can route differently in different installations/repositories.
• Policy can disable triggers per repository.
• Familiar memory/model/skill/publication policy is available to the worker as a task policy snapshot.
• Tests cover two installations with colliding labels and bot usernames.
• Docs explain local TOML policy source versus hosted control-plane policy source.

Test Notes

Add router tests with two installation ids and the same coven:fix label producing different familiar ids or ignored routing according to policy.