Support managed background services for local sites

[chubes4]

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:

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:

• Studio Code: run the remote-session bridge as a background daemon #3300 added studio code remote-session start --detach, stop, status, PID-file handling, daemon logs, detached child process spawning, and stale PID cleanup.
• Studio Code: add /remote-session slash command #3315 added /remote-session start|stop in the REPL plus daemon status polling.
• Studio Code: detach remote-session by default and add attach subcommand #3347 made remote-session detached by default and added studio code remote-session attach for streaming daemon output.
• remote-session: show agent output in attach (STU-1696) #3366 improved attach output/diagnostics.
• Studio Code: don't expose share_screenshot outside the remote-session runtime #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:

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.