bug(cli): service delete reports 'sandbox not found' when given the service name — and sibling verb signatures are inconsistent

[dlynch90]

Environment

OpenShell 0.1.1, macOS (local driver). Noted during review alongside #3051 (accepted structured-errors epic) — this is a CLI ergonomics case for it.

Reproduction

openshell service expose web 8080 web-http      # <SANDBOX> <TARGET-PORT> [SERVICE]
openshell service delete web-http
# × delete service failed: sandbox not found

The actual signature is service delete <SANDBOX> [SERVICE], so web-http was interpreted as a sandbox name and the error reports the wrong noun ('sandbox not found' is literally accurate about the argument but misleading about the mistake).

Issues

1. The error doesn't hint that the first positional is a sandbox name; users naturally try service delete <service-name> because that's the resource being deleted.
2. Sibling verbs have inconsistent positional order: service expose <SANDBOX> <TARGET-PORT> [SERVICE] vs service delete <SANDBOX> [SERVICE] — the optional name moves from third to second position across the same noun group.
3. service expose prints the sandbox-qualified endpoint (web/web-http); a delete error for a name that exists as a service could disambiguate with something like: 'no sandbox named ; did you mean delete service on sandbox ?'.

Expected

• A correction-shaped error (did you mean / argument-role naming) instead of the bare resource-not-found.
• Consistent positional order across service subcommands, or named flags (--sandbox, --service) for both.

[kvnloo]

For the first fix I would avoid changing the positional CLI contract, since that creates compatibility questions for scripts.

The lowest-risk improvement seems to be making the error describe the argument role.

For:

openshell service delete web-http

instead of only:

sandbox not found

the CLI could report something like:

no sandbox named "web-http"; usage is service delete <SANDBOX> [SERVICE]

A second-level enhancement could look for an exact service-name match and provide a did you mean hint, but I would keep that out of the initial fix unless service lookup is already cheap and unambiguous.

Tests should cover:

• unknown sandbox;
• existing sandbox + unknown service;
• omitted optional service;
• valid delete.

That fixes the misleading noun without changing the existing command grammar.

If this gets accepted, I can take that narrow slice.