refactor(op-devstack): add unified Registry for component storage (Phase 2)

[teddyknox]

This PR introduces a unified Registry type for op-devstack that can replace the 14+ separate locks.RWMap instances currently used in the Orchestrator. This is Phase 2 of the ID type system refactor.

Problem

The current Orchestrator maintains separate registries for each component type:

type Orchestrator struct {
    batchers        locks.RWMap[stack.L2BatcherID, *L2Batcher]
    proposers       locks.RWMap[stack.L2ProposerID, *L2Proposer]
    challengers     locks.RWMap[stack.L2ChallengerID, *L2Challenger]
    l2ELs           locks.RWMap[stack.L2ELNodeID, L2ELNode]
    rollupBoosts    locks.RWMap[stack.RollupBoostNodeID, *RollupBoostNode]
    // ... 9 more
}

This leads to:

• No unified way to query "all components on chain X"
• Manual polymorphic lookups (checking multiple registries)
• Adding new component types requires new registry fields

Solution

A single Registry with secondary indexes:

type Registry struct {
    components map[ComponentID]any           // Primary storage
    byKind     map[ComponentKind][]ComponentID  // "All batchers"
    byChainID  map[eth.ChainID][]ComponentID    // "All on chain 420"
}

Type-safe access via generic functions:

// Register and retrieve with compile-time type safety
RegistryRegister(r, batcherID, batcher)
batcher, ok := RegistryGet[*L2Batcher](r, batcherID)

// Query by kind or chain
batchers := RegistryGetByKind[*L2Batcher](r, KindL2Batcher)
components := RegistryGetByChainID[*L2Batcher](r, chainID)

Changes

File	Description
stack/registry.go	Unified Registry implementation
stack/registry_test.go	Comprehensive test suite (21 tests)
stack/component_id.go	Added HasChainID() helper
Design document	Phase 2 implementation notes

Test Plan

• Basic CRUD operations (Register, Get, Has, Unregister)
• Secondary index queries (GetByKind, GetByChainID)
• All three ID shapes (key+chain, chain-only, key-only)
• Replace behavior (same ID registered twice)
• Index cleanup on unregister
• Concurrent access safety
• Type-safe generic accessors
• Range iteration with early termination

Migration Path

This is non-breaking. The Registry can coexist with existing locks.RWMap fields:

1. Orchestrator can optionally maintain a Registry alongside existing maps
2. New code can use Registry, old code continues using maps
3. Phase 3 will add capability interfaces for polymorphic lookups
4. Phase 4 will migrate Orchestrator to use Registry exclusively

[ajsutton]

LGTM.