Idea: composite capability registry — CDI-aggregated multi-contributor SPI

[mdproctor]

Idea

During Epic 2 design we chose the simpler single-bean @Alternative override pattern for CapabilityRegistry. This issue captures the composite aggregation variant so it is not forgotten.

What it is

A composite CapabilityRegistry that collects all CDI-discovered implementations simultaneously, rather than one active bean at a time. In the app module:

@ApplicationScoped
public class CompositeCapabilityRegistry {
    @Inject Instance<CapabilityRegistry> registries;

    public Set<String> capabilities() {
        return registries.stream()
            .flatMap(r -> r.capabilities().stream())
            .collect(toSet());
    }

    public Optional<Double> threshold(String capability) {
        return registries.stream()
            .map(r -> r.threshold(capability))
            .filter(Optional::isPresent)
            .map(Optional::get)
            .findFirst();
    }
}

Any deployed module that provides a CapabilityRegistry bean automatically contributes its capabilities without modifying existing code.

Use cases that would justify this

1. Security plugin module — a devtown-security-extended jar ships SastCapabilityRegistry adding "sast-scan", "dependency-audit" without touching core devtown code.
2. Compliance overlay — a devtown-compliance module adds "gdpr-check", "pci-scope-review" for regulated environments; non-regulated deployments simply omit the jar.
3. Org-specific extensions — a private internal jar contributes org-specific capability tags (e.g. "internal-arch-review") without forking devtown.
4. Cross-domain platform convergence — if aml and clinical follow the same pattern, a generic CompositeRegistry<T> utility in casehub-engine or a shared module could eliminate the one aggregation loop each app currently repeats. Justified only if 3+ domain repos actually implement it.

Why we deferred it

• YAGNI: no concrete multi-contributor use case exists yet
• @Alternative override is already the platform pattern for WorkerSelectionStrategy
• Composite adds a for-loop of boilerplate; worth it only when multiple simultaneous contributors are a real requirement
• Platform consolidation value only materialises when ≥3 domain repos (devtown, aml, clinical) each independently implement the pattern and the shared utility pays for its dependency weight

Promote when

• A second CapabilityRegistry contributor exists in the same deployment, OR
• Two other domain repos (aml, clinical) have independently implemented the same aggregation pattern and a shared utility would eliminate the duplication