Make workload Configure registration transactional

Today `WorkloadRegistration.RegisterWorkloadsAsync` calls each workload's `Configure(builder)` directly against the live `IServiceCollection`. If a workload registers services and then throws, the partial registrations are left in DI. We isolate the failure (warn and continue) but not its side effects.

Follow-up from #4941 (Fabio review).

**Acceptance:**
- A workload's `Configure` either fully applies or leaves the host `IServiceCollection` unchanged.
- Likely approach: stage Configure into a child `IServiceCollection`, copy into the real one only on success.
- Add a regression test for a workload that throws after registering a service.

**Out of scope:** rolling back side effects beyond DI registrations (file writes, etc.) — workloads must not do those in Configure.

Start at WorkloadRegistration.RegisterWorkloadsAsync and trace how each workload's Configure(builder) writes to the live IServiceCollection. Add the regression test for a workload that registers a service and then throws; done means the failure is warned and continued while the host IServiceCollection remains unchanged, and successful configuration is applied.

Written by the indexing model from the issue text.