Metric 0.1.7

This release makes migrations from Sentry less disruptive and makes personal API
tokens fine-grained enough for build-tool and CI workflows.

What's new

• Keep existing Sentry DSNs during migration. Metric can map an existing Sentry
  public key and external project ID to a Metric project, so deployed clients do
  not need a DSN configuration change. The existing public hostname, port, TLS
  endpoint and any path prefix still need to route to Metric. Imported mappings
  use dedicated Metric keys and keep the normal project policy, rate limits and
  revocation behavior. See
  Move from Sentry without changing client DSNs.
• Fine-grained personal API tokens. Keep the existing presets or use
  Custom / Advanced to select individual scopes. The UI only exposes scopes
  that the creating user currently holds, and organization owner/delete permissions
  are intentionally not exposed as personal-token checkboxes.
• Sentry CLI and build-tool uploads. The new Sentry CLI uploads preset grants
  debug_file:read, debug_file:write, artifact:read, and artifact:write.
  This fixes source-bundle and artifact-bundle upload flows that previously returned
  403 because the token UI could not grant artifact:write.
  Thanks for #6!
• Schema generation 21. Existing generation-20 installations migrate
  automatically to generation 21, which adds the DSN mapping collection. A complete
  generation-19 installation runs the registered 19 → 20 → 21 migration chain.

Updating from 0.1.6

Back up the Metric database, BlobStore and installation secrets together before
updating. Keep the existing secrets and follow the
update guide.

Metric 0.1.6 uses schema generation 20. On first startup, 0.1.7 automatically
migrates a complete generation-20 database to generation 21. A generation-19
database runs both registered transitions. Databases older than generation 19 are
not supported by this migration chain; do not erase them or edit their schema marker.

During migration, normal API/SDK requests receive HTTP 503 and /ready stays
unavailable; /live remains healthy. Behind Kubernetes Ingress, use logs or a direct
pod port-forward to see progress while the pod is not ready.

Migrations are forward-only. Switching the image back to 0.1.6 does not undo the
database migration. Returning to that version requires restoring the pre-upgrade
database and matching blob backup, with the original secrets.