Support managed background services for local sites

## Problem

Studio makes it easy to run a local WordPress site, but long-running site-local work still requires an attached terminal or ad hoc shell backgrounding. That is fragile for agentic/dev workflows that need queue workers, importers, indexers, sync loops, or automation runners to keep working after the initiating terminal/session exits.

Concrete case: Data Machine now has a WP-CLI worker command that can run continuously:

```bash
studio wp datamachine worker run --time-limit=0 --sleep=30 --path ~/Studio/intelligence-chubes4
```

It can drain Action Scheduler/Data Machine work safely, but today the practical options are:

- keep an OpenCode/terminal session attached, which defeats the point of a background worker
- use raw `nohup ... &`, which creates orphan/duplicate/log cleanup problems
- build plugin-specific process supervision, which puts lifecycle concerns in the wrong layer

## Existing prior art

Studio already has a daemon/process-management pattern in the Studio Code remote-session work:

- #3300 added `studio code remote-session start --detach`, `stop`, `status`, PID-file handling, daemon logs, detached child process spawning, and stale PID cleanup.
- #3315 added `/remote-session start|stop` in the REPL plus daemon status polling.
- #3347 made remote-session detached by default and added `studio code remote-session attach` for streaming daemon output.
- #3366 improved `attach` output/diagnostics.
- #3365 tightened remote-session runtime behavior for screenshot tooling.

This issue is not asking Studio to invent daemon support from scratch. The ask is to generalize the useful parts of the remote-session daemon pattern into a reusable per-site service primitive.

## Proposal

Add a generic Studio-managed site service/background process primitive. For example:

```bash
studio site service start datamachine-worker --path ~/Studio/intelligence-chubes4 -- \
wp datamachine worker run --time-limit=0 --sleep=30

studio site service list --path ~/Studio/intelligence-chubes4
studio site service status datamachine-worker --path ~/Studio/intelligence-chubes4
studio site service logs datamachine-worker --path ~/Studio/intelligence-chubes4
studio site service attach datamachine-worker --path ~/Studio/intelligence-chubes4
studio site service stop datamachine-worker --path ~/Studio/intelligence-chubes4
studio site service restart datamachine-worker --path ~/Studio/intelligence-chubes4
```

The key is that Studio owns process lifecycle, not plugin semantics.

## Desired behavior

- Named services are registered per site.
- Studio prevents duplicate processes for the same service name.
- Studio captures stdout/stderr to predictable log files.
- Studio tracks PID/liveness and exposes it via CLI, ideally also `studio site status --format=json`.
- Studio can attach to a running service log/output without owning the service lifetime.
- Services stop when the site stops.
- Services can restart after site restart when configured.
- Optional restart policies: `never`, `on-failure`, `always`.
- Commands run inside the same WP/PHP context as `studio wp`.

## What this unlocks

- Local parity with production-style background workers and queues.
- Safer agent automation: agents can start a named service, inspect status/logs later, and avoid terminal-runner timeouts.
- Plugin developer ergonomics for queue consumers, importers, indexers, MCP/agent bridges, and sync loops.
- Cleaner separation of concerns: plugins own work semantics; Studio owns local process supervision.
- A reusable implementation path for features that currently need one-off daemon behavior.

## AI assistance

- **AI assistance:** Yes
- **Tool(s):** OpenCode (GPT-5.5)
- **Used for:** Drafting and refining the issue body from a local Data Machine worker debugging session; Chris directed the feature request and reviewed the need.

Start by reading the remote-session process-management work described in #3300, #3315, #3347, #3366, and #3365, then trace the existing `studio code remote-session` commands and site lifecycle entry points. The work is done when named per-site services support start, list, status, logs, attach, stop, restart, lifecycle handling, and the stated PID, duplicate, logging, and restart-policy behavior.

Written by the indexing model from the issue text.