Bidirectional handler↔module dependency in handlers/pipeline.go

[intel352]

Problem

The handlers package directly imports and holds concrete types from the module package (*module.Pipeline, *module.StepRegistry). This creates a bidirectional dependency and means handlers cannot be tested without instantiating real module types.

Fix Direction

Define PipelineRunner and StepRegistry interfaces in a shared package (e.g. workflow/interfaces or as part of the plugin contract). Have handlers depend on these interfaces; module implements them. This breaks the import cycle and enables proper unit testing of handlers with mocks.

Context

See docs/DEFERRED_ISSUES.md — Architecture section.