status:stopped config leaves a crashed pipeline labeled Degraded/Recovering

Follow-up from #2061 / PR #2512 (review nit).

#2512 makes a `status: stopped` config convert a `StatusSystemStopped` pipeline to `StatusUserStopped` on restart, so it isn't auto-resumed. That fully fixes the data-path bug (a stopped pipeline writing to its destination).

Edge, cosmetic only: a pipeline whose config says `stopped` but which crashed while `Recovering` or `Degraded` restarts with that label intact. It is **functionally stopped** — `lifecycle.Init` only auto-resumes `SystemStopped`, so no records flow and there are no destination writes — but its status *reads* `Recovering`/`Degraded` rather than `UserStopped`, which misrepresents the operator's intent.

Deliberately left out of #2512 to keep that Tier-1 fix narrow (`SystemStopped`-only guard). If we want config to fully own the status label, the guard in `provisionPipeline` could widen to convert any non-running, non-user-stopped state to `UserStopped` when the config says stopped — but that's a broader change and deserves its own review.

No data loss / no invariant impact; label-accuracy only.

Start by reading the guard in provisionPipeline and lifecycle.Init, then trace how a stopped configuration handles Recovering and Degraded pipeline states after a crash. Compare the existing SystemStopped and UserStopped behavior. Done means the status label reflects the stopped configuration without allowing auto-resume or destination writes.

Written by the indexing model from the issue text.