Service manager step 6: Planner (dependency resolution and action DAG)

Nobody has claimed this yet.

## Summary

Implement a stateless planner that diffs current vs desired service state, detects dependency cycles, topologically sorts services, and produces a DAG of Start/Stop/Restart actions. Used at boot and for runtime service changes.

This is step 6 of the service manager implementation (#26). Depends on step 5 (#31) for service configs.

## Desired behaviour

- Input: set of `ServiceConfig`s (desired state) + current running services (current state)
- Output: ordered list of actions (Start, Stop, Restart) that transitions current → desired
- Detects dependency cycles and reports them as errors
- Topological sort ensures dependencies start before dependents
- Stateless: can be re-run at any time to compute a new plan

## Algorithm

1. Build dependency graph from service configs
2. Detect cycles (error if found)
3. Topological sort to determine start order
4. Diff current vs desired: new services → Start, removed → Stop, changed config → Restart
5. Order Stop actions in reverse dependency order
6. Return action DAG

## Key files

- `userspace/init/src/planner.rs` — new module
- Types: `Plan`, `Action` (Start/Stop/Restart), `PlanError` (cycle detected, missing dependency)

## Testing

- Unit test: linear dependency chain A → B → C, verify start order
- Unit test: diamond dependency, verify correct ordering
- Unit test: cycle detection (A → B → A)
- Unit test: diff — add new service, remove old service, change config
- Unit test: empty plan when current matches desired
- Unit test: missing dependency reference produces clear error

## Documentation

- Doc comments on the planner API
- Document the action ordering guarantees
- Document how the planner handles partial failures (e.g., a dependency failed to start)

Part of #26

Start with the ServiceConfig types from step 5 (#31) and the service-manager integration around userspace/init; the new planner belongs in userspace/init/src/planner.rs. Define the Plan, Action, and PlanError behavior from the issue, then add unit tests for dependency ordering, cycles, diffs, empty plans, and missing dependencies. Done means the planner produces deterministic ordered actions and documents its ordering and partial-failure guarantees.

Written by the indexing model from the issue text.