WIP: feat(metrics): implementation of metric tasks

[project-defiant]

Motivation

We need a lightweight, reproducible way to compute and record key counts for every
dataset produced by the pipeline — total rows, distinct values, group distributions —
so we can track data quality and catch regressions across releases. This PR introduces
the pts.metrics framework and a standalone metrics.yaml config that covers all 32
datasets.

---

What's new

pts.metrics — metric definition framework

A Polars-based framework for declaring, computing, and serialising dataset metrics.

• Metric (abstract) — Pydantic base; subclasses declare config fields and implement
  compute(df). run() guards against empty DataFrames and wraps with debug logging.
• MetricResult (abstract) — to_unified_record() serialises metric-specific fields as a
  JSON blob into a flat UnifiedMetricRecord, which is written as one Parquet row per
  metric.
• Built-in types — count, distinct_count, grouped_count, grouped_count_explode,
  grouped_sum.
• Custom types — l2g_significant_gene (genes with L2G score ≥ threshold).
• MetricType enum — member name = YAML type field, value = implementer class.
  MetricType.load(cfg) is the single constructor used throughout; adding a new metric
  type is a one-liner in the enum.
• Null keys are preserved as their own group in all grouped metrics (no silent data
  loss).
• Parquet is read with per-metric column projection to minimise memory use; recursive
  **/*.parquet glob supports nested partitions.

CollectMetrics — otter task

• CollectMetricsSpec validates metric definitions at config-load time.
• Metrics are run concurrently via ThreadPoolExecutor — one thread per metric, so
  parquet reads and Polars computations overlap.
• Output is a single Parquet file with one row per metric, stamped with release, run,
  dataset, source, and destination.

Config

• metrics.yaml — standalone otter config covering all 32 datasets. Run any step with
  pts -s -c metrics.yaml.
• config.yaml — collect_metrics steps added alongside the existing transform steps.

---

Testing

• Unit tests for EmptyDatasetError, abstract-class enforcement, spec validation,
  scratchpad key checks, YAML config validity, end-to-end Parquet output, relative path
  resolution, and bad-column error propagation.
• Doctests in count.py and grouped.py covering single- and multi-column cases with null
  groups.
• All 356 tests pass. All 32 metrics.yaml steps verified against real data.

---

Notable design decisions

• MetricType enum over a registry dict — adding a new type is one line; no separate
  registration step.
• field_serializer on CollectMetricsSpec.metrics — necessary because Pydantic v2
  serialises list[Metric] using only base-class fields, stripping subclass fields during
  otter's internal model_dump round-trip.
• ThreadPoolExecutor over asyncio — Polars has no async API; threading gives real
  concurrency without the complexity of wrapping sync code in asyncio.to_thread.
• pts CLI, not otter — the otter CLI only registers built-in task types; pts also
  registers pts.tasks, which is where CollectMetrics lives.