feat: --no-proxy mode for app deploy/logs/status/stop/restart/destroy/init (TLS-less single-slot)

[crowdy]

Background

The conoha-proxy refactor (#98) removed the old single-slot, TLS-less deploy path. Use-cases that still want the simple flow:

• Testing without a public domain / DNS propagation.
• One-off hobby apps where blue/green + HTTPS is overkill.
• Services that expose arbitrary protocols (non-HTTP) — proxy can't route those.
• Intranet / dev VPS without inbound 80/443.

Proposal: add --no-proxy mode as a first-class alternative path across the `conoha app *` command tree, coexisting with the proxy-based flow on the same server.

Semantics per subcommand

Command	--no-proxy behavior
`app init`	Install Docker only. Skip conoha.yml load and proxy service upsert.
`app deploy`	tar upload → `/opt/conoha//` → `docker compose -p up -d --build`. Host ports from compose file. No conoha.yml required (use `--app-name`). .env preservation as in v0.1.x.
`app logs`	`docker compose -p logs`
`app status`	`docker compose -p ps` (no proxy phase section)
`app stop` / `restart`	`docker compose -p stop/restart`
`app destroy`	`docker compose down` + `rm -rf /opt/conoha//`. Skip proxy DELETE.
`app env`	Legacy `/opt/conoha/.env.server` path (current behavior — already no-proxy-aware).
`app rollback`	Unsupported, explicit error.

Mode selection

Three options to decide between:

1. Explicit flag only. User must pass `--no-proxy` every time. Simplest, most predictable.
2. Auto-detect from conoha.yml. No file / no `hosts:` → no-proxy. Convenient but surprising.
3. Hybrid (recommended): auto-detect + explicit `--proxy` / `--no-proxy` override.

Design constraints

• Single-slot and blue/green layouts must coexist on the same server:
  • Proxy-mode: `/opt/conoha///` + `CURRENT_SLOT`
  • No-proxy: `/opt/conoha//` (flat; no `CURRENT_SLOT`)
  • `destroy` must wipe both cleanly based on mode detection.
• `app deploy --no-proxy` on a proxy-initialized app must be rejected (would leave stale proxy service registration).
• `--app-name` flag is required when no `conoha.yml` is present.

Overlap with existing issues

• app logs/stop/restart/status: target active slot, not legacy /opt/conoha/<app> #93 (legacy path references in logs/stop/restart/status): this issue subsumes that — legacy paths become the no-proxy mode, not dead code.
• app env: redesign for blue/green + accessory separation #94 (app env redesign): `app env` already matches the no-proxy model. Proxy-mode needs a different answer, covered there.
• Re-implement conoha app reset for blue/green model #92 (`app reset` reintroduction): reset would need `--no-proxy` too; decide whether a reset across modes even makes sense.

Acceptance

• All listed subcommands accept and respect `--no-proxy`.
• Mode auto-detection documented (if chosen).
• README + recipes demonstrate both modes with concrete examples.
• No-proxy tests that mirror existing proxy-mode test coverage.
• `app destroy` safely cleans up either mode.

Out of scope

• Restoring v0.1.x git-push-deploy path. That's dead. Users who want it can use manual git remote + bare repo.
• Routing non-HTTP services via proxy. Proxy is HTTP-only by design.

References

• Spec: `docs/superpowers/specs/2026-04-20-conoha-proxy-deploy-design.md` §2 discusses the original decision for "full replacement (option A)". This issue revisits that trade-off.