docs: restore the wrong-service-name warning, corrected (86c990cfh)

[Babissimo]

Corrects a mistake in #212.

#212 deleted this ONBOARDING warning, arguing that the compose service rename had resolved the trap it described. Both the conclusion and the reasoning were wrong.

The trap was never "compose returns nothing". It is that naming a service which does not exist fails with no such service on stderr, so a grep over the output matches nothing and reads as a clean "no errors in the logs". That is precisely what produced a false all-clear on production on 2026-08-14, where re-running with the right name immediately surfaced repeated _refresh_mlat_verification tracebacks and solver-degradation warnings.

I measured the behaviour while writing #212 (no such service on an unknown name, silence on a known one with nothing running) and drew the wrong conclusion from it: I read "errors loudly" as self-correcting, without accounting for the grep pipeline that swallows stderr, which is the whole mechanism.

The rename does not remove the trap. It swaps which name triggers it, and the new losing guess is tower-finder — the name in every saved command, older ticket and operator's memory. The warning is therefore worth more after the rename than before it.

Restored with the mechanism stated properly, and pointed at docker compose ps --services as the thing to trust over any remembered name.

[claude]

Claude finished @Babissimo's task in 1m 20s —— View job

---

Reviewing PR #215

• Gather context (diff, ONBOARDING.md, PR rename: compose service tower-finder becomes server (86c990cfh) #212 history)
• Understand the request (code review)
• Review the restored warning text
• Post findings

Review

This is a docs-only change (+4/-0 in ONBOARDING.md), restoring a "things that will bite you" bullet that #212 had deleted. I checked the factual claims against the repo:

• Service name: docker-compose.yml does define the service as server (line 20), not tower-finder — confirmed. The bullet's core claim is accurate.
• stderr mechanism: docker compose logs <bad-name> fails with no such service on stderr in compose v2, which is exactly the trap described — a grep-over-stdout pipeline would see nothing and read as clean. This is a materially different (and correct) mechanism than what rename: compose service tower-finder becomes server (86c990cfh) #212's commit message assumed ("fails loudly" / "trap no longer exists") — rename: compose service tower-finder becomes server (86c990cfh) #212 conflated "errors" with "errors somewhere grep will see them."
• Suggested check: docker compose ps --services is a reasonable, low-friction way to verify the real service name before trusting a remembered one.
• Style: consistent with the rest of the "Things that will bite you" section — bold lead sentence, backtick code spans, single-asterisk italics for emphasis (matches the existing *base* usage a few bullets up).

One very minor nit, not worth blocking on:

• ONBOARDING.md:241 runs a bit longer (~88 chars) than the soft wrap width used by neighboring bullets (~80–83 chars). Rewrapping would make it consistent, but it's cosmetic only.

No correctness issues found. This restores accurate, more valuable information (the rename made tower-finder the new losing guess, so the warning is arguably more relevant now, not less) and matches actual repo state.