RI capabilities: register erc3643/erc4626/irs in CapabilityFactoryMap (FR-014) — needs ui-types signature evolution

Context

Follow-up from Phase 6 (US5) of 002-ri-evm-capabilities. This references work on branch 002-ri-evm-capabilities that is committed locally but not yet pushed to the remote, so the file paths/line references below may shift before merge.

Phase 6 shipped the three RI capabilities as sub-path exports (@openzeppelin/adapter-evm/erc3643, /irs; erc4626 lands in Phase 7) and as named exports on the public package (createERC3643, createIRS via packages/adapter-evm/src/capabilities/index.ts). This satisfies FR-021 (direct / sub-path consumption — the path the RI plugin actually uses per quickstart.md).

It did not complete T037 / FR-014: registering them in capabilityFactories + ecosystemDefinition.capabilities.

Why it's blocked

@openzeppelin/ui-types types the map entries as:

erc3643?: (config: NetworkConfig) => ERC3643Capability;
erc4626?: (config: NetworkConfig) => ERC4626Capability;
irs?:     (config: NetworkConfig) => IRSCapability;

But these factories bind per-deployment state at construction that a config-only signature cannot supply:

• createERC3643(config, { signAndBroadcast, tokenAddress })
• createIRS(config, { signAndBroadcast, addresses })

The capability methods take holder/amount args, not a per-call contract address — so the token/registry addresses must be bound at factory time. accessControl works in the map only because it takes contractAddress per call. Per-deployment RI addresses do not belong in the shared NetworkConfig (one network hosts many RI deployments).

Options to resolve

1. Evolve the CapabilityFactoryMap signature in @openzeppelin/ui-types to allow optional capability-specific construction options, then register properly (cross-repo published-type change; follow the FR-022 release sequence: ui-types first).
2. Keep RI capabilities direct/sub-path only for the POC and relax/clarify FR-014 to treat named + sub-path exports as sufficient (no map entry).

Recommendation: option 1 if/when a runtime that resolves capabilities by name (not just direct construction) needs these; otherwise option 2 keeps the POC honest.

Acceptance

• Decide between (1) and (2); if (1), land the ui-types signature change + register erc3643/erc4626/irs in capabilityFactories and ecosystemDefinition.capabilities without adding them to any pre-composed profile (FR-021).
• Wire erc4626 map/registration alongside Phase 7.

See specs/002-ri-evm-capabilities/tasks.md (T037) for the inline deferral note.

Start with the CapabilityFactoryMap definition in @openzeppelin/ui-types and the deferred T037 note in specs/002-ri-evm-capabilities/tasks.md. Review the existing capabilityFactories and ecosystemDefinition.capabilities registrations, alongside packages/adapter-evm/src/capabilities/index.ts. Done means deciding between the two stated options, and if choosing registration, evolving the signature and registering all three capabilities without adding them to a pre-composed profile.