Add decision-latency and build-info metrics

If the thing meant to protect your service's latency (the rate limiter) becomes the cause of latency -- a struggling Redis instance, say -- that should be visible and alertable well before customers notice. Without a per-decision latency metric, that degradation is invisible until it's already user-facing, turning a preventable, quietly-escalating problem into a customer-facing incident with no early warning. Build-info similarly matters operationally: during an incident, "did the fix actually deploy to this environment" is one of the first questions asked, and today there's no way to answer it from /metrics alone.

internal/api/metrics.go exposes exactly one metric, ratelimiter_decisions_total{rule,allowed} (a counter), recorded from handleCheck and every demo route via recordDecision. There is no per-decision latency metric and no build-info metric.

curl -s -X POST localhost:8080/api/v1/check -d '{"rule":"free-tier","key":"user-123"}' curl -s localhost:8080/metrics | grep ratelimiter_decision_duration_seconds // got: (nothing -- the series does not exist) // want: at least one observation with a rule label

A rate limiter that becomes the slowest thing in your request path (because its backend is struggling) is a classic "the fix became the problem" failure mode, and it's invisible without per-decision latency metrics. Teams that only alert on request-level latency discover this after the fact, when customers are already affected.

Use promauto.NewHistogramVec / promauto.NewGaugeVec (or NewGauge with a Set(1) if you don't need the label dimension) -- the same package already imported in this file. Time the limiter call with time.Since/time.Now() around the existing limiter.AllowN(...)/limiter.Allow(...) call sites, not around the whole HTTP handler (which would also count JSON encoding, etc.).