dapr init: option to run Sentry in self-hosted mode

[JoshVanL]

Problem

In self-hosted mode, dapr init does not start the Sentry service. Users who
want mTLS and any feature that depends on it currently have to install or
build Sentry separately, generate or supply certs, set
DAPR_TRUST_ANCHORS / DAPR_CERT_CHAIN / DAPR_CERT_KEY env vars, and run
./sentry themselves before they can use the feature. See Setup & configure
mTLS certificates (self-hosted)
for the current manual steps.

This is friction for any feature that builds on the sidecar SPIFFE identity,
including:

• Workflow history signing (docs:
  dapr/docs#5082)
• Workflow access policies
• Service-invocation access control, secret-store scope checks, and anything
  else gated on workload identity in self-hosted mode

Proposal

Add a first-class option to dapr init that brings up a local Sentry as
part of the standard self-hosted setup. Sketch:

dapr init --enable-mtls # opt-in flag

What it should do:

1. Generate (or accept user-supplied) root/issuer certs into the standard
   $HOME/.dapr/certs/ location.
2. Start the Sentry service alongside the other Dapr self-hosted services
   (Docker container or native binary, matching the rest of dapr init's
   model).
3. Write a default Dapr configuration with spec.mtls.enabled: true so
   dapr run picks it up without extra flags.
4. Wire the trust-anchor / cert-chain / cert-key env vars so existing
   sidecar launches work out of the box.
5. Surface a clear status line ("Sentry running, mTLS enabled, trust domain
   cluster.local") in dapr status / dapr init output.

Acceptance criteria

• dapr init --enable-mtls (or equivalent flag) provisions certs, starts
  Sentry, and produces a working mTLS-enabled self-hosted environment in
  one command.
• dapr run against that environment gets a valid SPIFFE SVID without
  additional env-var plumbing from the user.
• dapr uninstall cleans up Sentry alongside the other services.
• Docs updated: self-hosted mTLS setup, workflow history signing
  prerequisites, workflow access policy prerequisites.

Out of scope

• Bring-your-own-CA flow (already supported via existing cert flags; this
  issue is about the zero-config default).
• Kubernetes (dapr init -k already installs Sentry).