fix(capabilities): same-provider-type URI scheme registration idempotent

[Million-mo]

Problem

A manifest with per-agent capability variants of the same provider type crashed at pool init. UriSchemeRegistry.register() treated the second claim of a scheme as a conflict and aborted startup:

UriSchemeConflictError: URI scheme 'viking' is already claimed by 'VikingCapability';
cannot register 'VikingCapability'
RuntimeError: Failed to initialize agent pool

Concrete case: xeno-agent's Hongshan config declares three separate type: viking capabilities (knowledge-base, vision, and research agents, differing in support_vision, enable_memory, and tool filters). Each instance claims the viking URI scheme; only the first could register.

Fix

UriSchemeRegistry.register() now treats a scheme already claimed by another instance of the same provider type as an idempotent no-op: the first claimant keeps ownership, later same-type instances are ignored. Only a genuinely different provider type claiming an already-owned scheme still raises UriSchemeConflictError. Registration remains all-or-nothing (conflict on any scheme aborts before any mutation).

Per-agent behavior is unaffected: each capability instance stays registered at AGENT scope in the ExtensionRegistry, so its own tools, memory, and URI-guard settings apply. The scheme registry only routes scheme:// resource URI lookups.

Verification

• New tests/capabilities/test_uri_scheme_registry.py (10 unit tests): registration/lookup/unregister, same-type idempotency, cross-type conflict (incl. no-partial-commit), and a regression test mirroring AgentFactory.register_config_capabilities with three type: viking agents.
• Full capabilities unit suite: 1219 passed, no regressions.
• ruff check / ruff format clean; mypy --strict clean on changed files.
• End-to-end: wolfharness serve-acp config/diag-agent-hongshan.yaml now passes pool init (server starts and stays up) instead of exiting code 1.

Changelog: changelog/unreleased/2026-09-01-same-type-scheme-registration.md