feat(deckies): live service add/remove without full redeploy

decnet.engine.services_live exposes add_service / remove_service for
both fleet and topology decky scopes.  The host's _compose() wrapper
already supported per-service targeting (up --no-deps -d <svc>,
stop, rm -f); what was missing was the orchestration around it:

* add: validate against decnet.services.registry (rejects unknown +
  fleet_singleton); persist the new services list; re-render the
  per-scope compose file (so future redeploys reflect the change);
  run docker compose up -d --no-deps --build <decky>-<svc>.
* remove: stop + rm -f the service container; persist; re-render
  compose so a future up -d doesn't bring it back.

Both publish decky.<name>.service.added / .removed on the bus, with
the post-mutation services list.  Topic constants added to
decnet.bus.topics; the matching wiki entry in wiki-checkout/Service-Bus.md
ships in a separate commit on the wiki repo (wiki-checkout/ is gitignored).

Four new admin endpoints:

* POST/DELETE /api/v1/deckies/{name}/services{,/svc}
* POST/DELETE /api/v1/topologies/{id}/deckies/{name}/services{,/svc}

ServiceMutationError messages are mapped at the API boundary to 404
(decky/topology missing), 409 (idempotency violation), 422 (unknown
or fleet_singleton service).

decnet/web/db/models/__init__.py

@@ -66,6 +66,8 @@ from .deploy import (
 from .decky import (
     DeckyFileDeleteRequest,
     DeckyFileDropRequest,
+    DeckyServiceAddRequest,
+    DeckyServicesResponse,
 )
 from .fleet import (
     LOCAL_HOST_SENTINEL,
@@ -228,6 +230,8 @@ __all__ = [
     "LOCAL_HOST_SENTINEL",
     "DeckyFileDeleteRequest",
     "DeckyFileDropRequest",
+    "DeckyServiceAddRequest",
+    "DeckyServicesResponse",
     "FleetDecky",
     # health
     "ComponentHealth",

decnet/web/db/models/decky.py

@@ -44,6 +44,27 @@ class DeckyFileDropRequest(BaseModel):
         return v
 
 
+class DeckyServiceAddRequest(BaseModel):
+    """Add a single service to an already-deployed decky.
+
+    The service must be registered (see :mod:`decnet.services.registry`)
+    and must NOT be ``fleet_singleton`` — those run once fleet-wide,
+    not per-decky.  Validation happens server-side in the engine layer
+    and surfaces as 422.
+    """
+    name: str = PydanticField(..., min_length=1)
+
+
+class DeckyServicesResponse(BaseModel):
+    """Post-mutation services list, returned by the live add/remove API.
+
+    Lets the dashboard reflect the new shape without a follow-up GET.
+    """
+    decky_name: str
+    topology_id: Optional[str] = None
+    services: list[str]
+
+
 class DeckyFileDeleteRequest(BaseModel):
     """Best-effort ``rm -f`` of an absolute path inside a decky container."""
     decky_name: str = PydanticField(..., min_length=1)