engine: output pin types are frozen at registration — MoQ nodes cannot retype pins to catalog-discovered codecs

[staging-devin-ai-integration]

Context

PR #566 (fixes #529/#530) makes MoQ subscriber paths resolve codecs from the remote catalog. However, the engine resolves output pin types once at node registration and provides no way to retype a pin afterwards, which forces side-channel workarounds and leaves residual gaps:

• Pre-declared peer pins: MoqPeerNode::output_pins() declares audio/data/video/data typed with the local codec config. The engine creates distributors for declared pins at registration (dynamic_actor.rs), so connections to them never go through RequestAddOutputPin and never consult the catalog-discovered codec map. Frame content_type is correct, but the pin produces_type can still advertise the wrong codec.
• Timing: an edge wired before the remote catalog arrives reads an empty discovered-codec map and falls back to local config.
• Design: both MoqPullNode and MoqPeerNode now carry a side map (transport/moq/discovered.rs) of catalog-discovered codecs keyed by pin name. This map exists solely to work around the frozen-pin-type limitation; it is pruned on pin removal, but it is inherently brittle (must be kept in sync with pin lifecycle manually).

Proposed direction

Add an engine-level mechanism for a node to retype (or defer typing of) an output pin after registration — e.g. a RetypeOutputPin pin-management message, or deferred pin-type resolution where a dynamic pin's type is finalized on first packet/catalog resolution and propagated to type validation.

With that in place, the discovered-codec side maps in transport/moq/ can be deleted and pins would always advertise the true negotiated codec.

Refs #529, #530, #568, PR #566.