Add gauge/counter semantics to metric declarations (ticket 097)

Metrics previously only declared a data type (String/Number/...), so
rate() could be applied to a point-in-time gauge reading and sum()/avg()
could be applied directly to a cumulative counter reading with no guard
against either. Adds a MetricSemantics enum (Gauge, default; Counter)
threaded through DeclareMetricRequest, the engine's MetricDeclaration
data value, profile persistence, the API/MCP declaration routes, and the
Metrics panel's declaration form, then uses it in evaluate_promql to
reject rate() on a declared gauge and bare sum()/avg() on a declared
counter (suggesting rate() first). The guard only applies to metrics
with a captured value_param — bare occurrence-count metrics are always
safe under both operations, so existing dashboards are unaffected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TeyhRfMYjMditek6geDRoQ

src/api/mcp_server.rs

@@ -69,6 +69,10 @@ pub struct DeclareMetricParams {
     pub matched_labels: Option<BTreeMap<String, String>>,
     #[serde(default)]
     pub unmatched_labels: Option<BTreeMap<String, String>>,
+    /// Whether this metric's value is a point-in-time reading ("gauge", e.g. queue depth) or a
+    /// monotonically-increasing total ("counter", e.g. requests served). Defaults to "gauge".
+    #[serde(default, skip_serializing_if = "Option::is_none")]
+    pub semantics: Option<String>,
 }
 
 #[derive(Debug, Deserialize, schemars::JsonSchema)]