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

## 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)](https://docs.dapr.io/operations/security/mtls/#self-hosted)
for the current manual steps.

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

- [Workflow history signing](https://github.com/dapr/dapr/pull/9778) (docs:
[dapr/docs#5082](https://github.com/dapr/docs/pull/5082))
- [Workflow access policies](https://github.com/dapr/docs/pull/5114)
- 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).