docs(skills): use the single miti-coolify MCP for both servers

miti-sg's Coolify now manages miti-jp too, so the skills search one MCP
server instead of two. Drop the stale gitea-mirror watch-path exception;
the new miti-jp app has its watch path set.

.claude/skills/debug-service/SKILL.md

@@ -35,10 +35,10 @@ Run `git log --oneline -10 -- <service>/`; a recent change is the first suspect.
 
 ## 3. Collect runtime evidence
 
-Coolify has two MCP servers, `miti-jp` and `miti-sg`; the service may live on
+One Coolify MCP, `miti-coolify`, manages both servers, `miti-sg` and
-either.
+`miti-jp`; the service may live on either.
 
-1. `search_resources` with the service name on both servers.
+1. `search_resources` with the service name.
 2. For a failed deploy: `list_deployments`, then `get_deployment` with
    `include_log_summary=true`.
 3. `get_logs` only when the resource is running; otherwise follow the

.claude/skills/migrate-service/SKILL.md

@@ -24,8 +24,8 @@ old resource stays intact until the user deletes it; it is the rollback.
 ## 1. Identify both resources
 
 Read `<service>/compose.yml` and `<service>/README.md`. Then
-`search_resources` with the service name on every Coolify MCP server
+`search_resources` with the service name through the Coolify MCP
-(`miti-jp`, `miti-sg`). The old one is usually a Service (`get_service`,
+(`miti-coolify`, which manages both servers `miti-sg` and `miti-jp`). The old one is usually a Service (`get_service`,
 `list_service_applications`, `list_service_databases`); the new one is an
 Application whose `git_repository` is this repo and `base_directory` is
 `/<service>`. If the new app does not exist, the user creates it first —

CLAUDE.md

@@ -55,7 +55,6 @@ After creating one, check `watch_paths` with the Coolify MCP `get_application`;
 
 - `traffmonetizer`, on both `miti-sg` and `miti-jp`, leaves it unset on purpose
   to be restarted on every push.
-- `gitea-mirror` on `miti-jp` is not a real setup; skip it.
 
 ## Service directories hold deploy files only