`import metrics` writes app-authored metric samples through the Vary
Server runtime contract. The runtime supplies the metrics endpoint and
the workload identity token at launch; the server derives the emitting
app from the token rather than from app-provided fields.

## API surface

```text
import metrics

metrics.write("requests_total", 1.0, "count", {"route": "/api/v1/issues"})
metrics.scalar("queue_depth", 12.0, "count")
```

| Function | Purpose |
|---|---|
| `write(metric_name, value, unit, tags)` | One sample with string tags. Defaults: `count`, `{}`. |
| `scalar(metric_name, value, unit)` | Same as `write` with no tags. |

`value` is a `Float`. `unit` is a string; common values are `count`,
`seconds`, `bytes`, and `ratio`. `tags` is a `Dict[Str, Str]`.

## Errors

All errors subclass `MetricError`:

| Error | Cause |
|---|---|
| `MetricBootstrapError` | `VARY_METRICS_URL` or `VARY_CONFIG_TOKEN_PATH` is unset. |
| `MetricAuthorizationError` | The workload identity token was rejected by the server. |
| `MetricValidationError` | Invalid metric name, unit, tag key, or tag value. |
| `MetricCardinalityError` | The server applied a cardinality cap to the metric. |

Treat metric writes as best-effort observability: catch `MetricError` at
the call site and continue. Do not fail a request because a metric write
failed.

## How Via surfaces them

Via exposes app-authored metrics through the operator surface
(`via metrics ...`) and through the per-app status block. App-side
metrics share the same retention policy as runtime metrics; the platform
applies cardinality limits before storage to prevent a runaway tag from
overwhelming the host.

Metric names should be lowercase, dotted or underscored, and stable
across releases. Reserve high-cardinality dimensions (user ids, request
ids) for log fields or audit events instead of metric tags.