refactor: introduce a services/ layer between routes and db/docker_client

[AbstractNucleus]

What: Route handlers call db.* and docker_client.* directly and also do cross-cutting business logic (port-collision scans, state transitions, RCON+offline routing in server_players.py).

Why: Routes are hard to test in isolation, and the same business rule (e.g. port collision) is restated in multiple places.

Approach: Introduce a services/ package — server_service, membership_service, lifecycle_service. Each route handler becomes thin orchestration; rules live in services.

[AbstractNucleus]

This was generated by AI during triage.

Routed to ready-for-human — introducing a services/ layer is a cross-cutting refactor that touches most route modules. The shape of the service boundary (per-aggregate vs per-use-case, whether services own transactions, what they return) is a design call that should be made before an agent starts moving code.

Suggest pairing this with #96 (cached Settings()) and #98 (shared docker client) since those are natural inputs to the service layer.

[AbstractNucleus]

Triage note: same recommendation as #100 / #101 — services/ extraction touches every route handler and conflicts with anything else in flight. Suggest landing after #119, #123, and the remaining a11y surface slices of #110.

Also a sequencing question between the three layout refactors: #97 → #101 → #100 reads as the lowest-churn order (carve services boundary first, then split files.py against that seam, then reshuffle top-level packages). Worth confirming before any of them start.

Holding for now.