Workflow availability check doesn't resolve Go templates in step `tool:` field, blocking all templated-dispatch workflows

[teemow]

Summary

Workflows whose step tool: field contains Go-template expressions (e.g. x_{{.input.mc}}-mcp-prometheus_execute_query) always fail execution with workflow ... is not available (missing required tools), even when the templated tool name resolves to a registered tool at runtime.

Repro

1. Create a workflow with a hardcoded tool: and run it — succeeds:

   steps:
     - id: probe
       tool: x_gazelle-mcp-prometheus_execute_query
       args: { query: "vector(1)" }

2. Create the same workflow with a templated tool: and pass the same value as input — fails:

   args:
     mc: { type: string, required: true }
   steps:
     - id: probe
       tool: x_{{.mc}}-mcp-prometheus_execute_query
       args: { query: "vector(1)" }

   Calling with {"mc": "gazelle"} → workflow ... is not available (missing required tools).

Same result with {{.input.mc}} rooting. Calling the underlying x_gazelle-mcp-prometheus_execute_query tool directly with the same query works fine, so the registered tool exists and is reachable — it's the workflow-level pre-execution check that rejects it.

Root cause (inferred)

The pre-execution "required tools" check looks up each step's tool: field literally in the static tool registry. Because Go-template substitution hasn't run yet, the lookup happens on the string x_{{.mc}}-mcp-prometheus_execute_query (or x_{{.input.mc}}-...), which isn't a registered tool name, so the check fails and the workflow is aborted before any step executes.

Impact

All 5 alert-triage workflows shipped in Muster are non-functional:

• mc-certificate-is-missing
• mc-container-restarting-too-frequently
• mc-cpu-usage-too-high
• mc-etcd-down
• mc-pod-pending-capi

They all use tool: x_{{.input.mc}}-... to dispatch to per-MC Prometheus/Kubernetes servers.

Proposed fix

The availability check should resolve Go-template expressions in tool: fields against the supplied workflow inputs before consulting the tool registry. Alternatively, defer the existence check to per-step execution so a templated-but-resolvable tool isn't rejected up front.

Related: template-root inconsistency

Separate but worth noting — the core_workflow_validate schema documents templating as {{.argName}}, but the shipped workflows use {{.input.argName}}. Both produce the same "missing required tools" failure here, so it's not the cause of this bug, but the schema doc and the workflow YAMLs should agree on one root.