fix: typed-nil guard and _response_handled parity for PipelineRunner fallback path

[Copilot]

routePipelines maps string → interfaces.PipelineRunner, so a caller can store a typed-nil *Pipeline as the interface value. The previous pipeline != nil guard passes for typed-nil interfaces, and the subsequent type assertion succeeds yielding a nil pointer — causing a panic on concretePipeline.Metadata = ….

The Run() fallback for non-*Pipeline implementations also lacked the _response_handled sentinel check present in the *Pipeline path, risking double-writes when a custom runner writes directly to the ResponseWriter.

Changes

• Typed-nil guard (command_handler.go, query_handler.go): Hoist the type assertion before the branch so both cases are covered with a single assertion:

  concretePipeline, isConcrete := pipeline.(*Pipeline)
  if isConcrete && concretePipeline != nil {
      // concrete *Pipeline path
  } else if !isConcrete {
      // PipelineRunner.Run() fallback
  }
  // typed-nil *Pipeline falls through to delegate/404

• _response_handled parity in Run() fallback: After pipeline.Run() returns, check result["_response_handled"] == true and skip JSON encoding if set — matching the behaviour of the *Pipeline path.

• Tests (command_handler_test.go, query_handler_test.go): Added mockPipelineRunner (shared across package module tests) and four new cases per handler:

  • mock runner result is JSON-encoded correctly
  • _response_handled=true suppresses the response body
  • Run() error yields a 500
  • typed-nil *Pipeline does not panic and falls through to 404

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.