feat(telemetry): add Prometheus runtime metrics

Problem

FaultPlane currently exposes basic runtime functionality, but the telemetry layer does not provide structured Prometheus metrics for monitoring workflow execution, recovery events, and system health.

Without metrics visibility, operators cannot easily understand runtime behavior, identify failures, or observe recovery performance.

---

Proposed Solution

Add Prometheus metrics support inside the telemetry package.

The implementation should:

• Add Prometheus metric collectors inside internal/telemetry/
• Expose runtime metrics through the existing metrics API endpoint
• Track workflow lifecycle events
• Track checkpoint operations
• Track recovery attempts and successful recoveries
• Track basic runtime health information

Suggested metrics:

• faultplane_workflows_total
• faultplane_checkpoints_total
• faultplane_recovery_total
• faultplane_recovery_success_total
• faultplane_runtime_info

---

Alternatives

Alternative approaches considered:

• Using only application logs for runtime visibility

  • Simple but difficult to query and aggregate.

• Using custom JSON metrics output

  • Requires additional tooling and does not integrate well with cloud-native monitoring systems.

Prometheus provides a standard observability interface for infrastructure systems.

---

Use Case

Operators running FaultPlane deployments need visibility into:

• Active workflows
• Recovery activity
• Checkpoint frequency
• Runtime health

These metrics will support debugging, dashboards, alerting, and future production deployments.

---

Additional Notes

Requirements:

• Keep telemetry implementation independent from business logic.
• Follow existing package structure.
• Add unit tests for metric registration and updates.
• Avoid introducing unnecessary dependencies.

Related areas:

• internal/telemetry/
• internal/api/metrics.go
• Operations Dashboard integration

Start by reading the existing telemetry package under internal/telemetry/ and the metrics endpoint in internal/api/metrics.go. Trace how the existing metrics API is exposed, then add collectors for workflow, checkpoint, recovery, and runtime health events while keeping telemetry independent from business logic. Done means the endpoint exposes the new metrics and unit tests cover their registration and updates.