feat: take the Sentry DSN from the environment

[lorem-dev]

DOPPEL_SENTRY_DSN provides the Sentry DSN, or replaces the one in the document.

Why

A DSN carries the key that authorises sending events, so it is the one Sentry
setting that is a credential. Until now the only way to give Doppel one was to
write it into a document the admin API returns and the store keeps -- which is the
same objection DOPPEL_ADMIN_TOKENS already answers for tokens.

The rules, and why each is the way round it is

• The environment wins over sentry.dsn. That is how a deployment overrides a
  document it may not be able to edit, and it is the precedence the admin tokens
  already have.

• An empty variable counts as unset and leaves sentry.dsn in force.
  DOPPEL_SENTRY_DSN=${SENTRY_DSN} with nothing behind SENTRY_DSN is a compose
  file that means nothing by it, and silently switching error reporting off is the
  worse reading. Turning it off is still dsn: "", or no section at all.

• Doppel reads its own name, not the conventional SENTRY_DSN. A variable
  sitting in the environment for the service beside this one should not make this
  one start reporting to it.

• The source is logged. "sentry reporting enabled" with a redacted DSN does not
  answer the question an operator has when it is the wrong DSN:

  {"level":"INFO","fields":{"message":"sentry reporting enabled",
   "dsn":"https://<redacted>@sentry.example.com/1","source":"DOPPEL_SENTRY_DSN"}}

• Read at startup, not merged into Config, like the other two environment
  values: the revision is a hash of the document, so folding the environment in
  would make two instances reading one stored document disagree about it.

• Validation stays at the client. The crate that knows what a DSN has to parse
  as is also the only one that can redact the key when it does not.

Verification

make gate clean, with both feature configurations of doppel-telemetry -- the
default build and --features sentry. Five unit tests on the precedence, two
through the built binary, which is the only place a variable is really read from a
process: one asserts the source is named and the key does not leak, the other that
an empty variable leaves a configured DSN alone.

Mutation-checked by ignoring the environment entirely: three tests fail, including
the end-to-end one.

Documented in the observability page, the configuration reference, the field's own
doc comment (so the schema and the generated parameter page carry it) and two lines
in the README beside DOPPEL_EXTERNAL_URL.