darkbloom doctor: actively guide un-enrolled/un-attested providers to MDM enrollment

## Background
A meaningful slice of the live fleet runs **un-attested** — `trust=self_signed`/`hardware untrusted` — because the Mac was never MDM/ACME enrolled. These providers can't receive **private** routing and they auto-upload log reports. In the recent log-report sample this showed up as ~60 `self_signed/online` + ~15 `hardware/untrusted` auto-report events across the fleet.

The mechanism to fix it already exists (`darkbloom enroll` requests the per-device `.mobileconfig`, opens it, and opens System Settings → Device Management). The problem is **discovery**: nothing tells an un-enrolled operator that they're in a degraded state or what to do about it.

## Current behavior
`darkbloom doctor` already *detects* the state but gives no actionable next step:
- `provider-swift/Sources/darkbloom/DoctorCommand.swift:245-250` — `mdm enrollment` check prints `[WARN] not enrolled; hardware trust may remain pending`.
- `DoctorCommand.swift:277-308` — `coordinator trust` check prints `trust=, proofs=self-signed only` as a `[WARN]`.

Both are buried in the check list, use soft language ("may remain pending"), and never mention `darkbloom enroll` or a console MDM/enrollment page. So an operator running `doctor` has no idea they need to act, or how.

## Desired behavior
When the machine is **not MDM-enrolled** (`checkMDMEnrolled() == false`) OR the coordinator reports **trust != hardware** for this serial, `darkbloom doctor` should:

1. Print a prominent, plain-language callout (not just a buried `[WARN]`) explaining the consequence: *"This Mac is not hardware-attested, so it will not receive private inference jobs."*
2. Give the exact next step and **auto-direct** them:
- Tell them to run `darkbloom enroll` (the canonical CLI flow — already implemented in `EnrollCommand.swift`), and/or
- Point them to the console MDM/enrollment page (e.g. `console.darkbloom.dev` provider setup) with the URL printed, and
- Optionally **auto-open** the enrollment flow / Device Management pane (behind a prompt or a `--fix`/`--enroll` flag so `doctor` stays read-only by default).
3. **Branch on enrollment state**: if not enrolled → drive to enroll; if enrolled but trust still pending → say "enrolled, attestation pending, retry shortly / re-run doctor"; if `hardware` → all good.

Consider surfacing the same guidance at the moment of impact:
- `darkbloom start` / `serve` startup (one-line warning + the enroll hint when un-attested), and
- `darkbloom status`.

## Acceptance criteria
- [ ] Running `darkbloom doctor` on an un-enrolled Mac prints a clear, unmissable instruction to enroll, including the exact command (`darkbloom enroll`) and/or the console enrollment URL.
- [ ] The message distinguishes the three states: not-enrolled, enrolled-but-trust-pending, and hardware-attested.
- [ ] An opt-in path (flag or prompt) actually opens the enrollment flow / MDM page; default `doctor` stays read-only.
- [ ] No false "go enroll" nag when the provider is already `trust=hardware`.
- [ ] Graceful when the coordinator/attestation endpoint is unreachable (don't hard-fail; fall back to local `checkMDMEnrolled()`).

## Implementation notes / references
- Doctor checks + trust fetch: `provider-swift/Sources/darkbloom/DoctorCommand.swift` (`buildCoordinatorDoctorChecks`, the `mdm enrollment` and `coordinator trust` checks, `ProviderAttestation.trustLevel`).
- Enrollment detection: `checkMDMEnrolled()` in `provider-swift/Sources/ProviderCore/Security/SecurityHardening.swift:321`.
- Existing enroll flow to reuse/trigger: `provider-swift/Sources/darkbloom/EnrollCommand.swift` (requests `POST /v1/enroll`, opens `.mobileconfig`, opens System Settings → Device Management).
- Coordinator enroll profile generation: `coordinator/api/enroll.go` (`handleEnroll`).
- Trust source of truth: coordinator `/v1/providers/attestation` (`trust_level`, `mdm_verified`/`acme_verified`/`mda_verified`).

## Out of scope
The actual attestation/trust mechanics work; this is purely the **provider-side UX** to detect un-enrolled state and route operators to enrollment.

Start in provider-swift/Sources/darkbloom/DoctorCommand.swift, especially buildCoordinatorDoctorChecks and the mdm enrollment and coordinator trust checks; read SecurityHardening.swift:321 and EnrollCommand.swift to understand existing detection and enrollment behavior. Check the coordinator attestation response fields and the start, serve, and status entry points. Done means doctor clearly distinguishes all three trust states, remains read-only by default, handles unavailable attestation gracefully, and provides an opt-in enrollment path without nagging hardware-attested providers.

Written by the indexing model from the issue text.