fix(orders): record why an exec order failed, and honour informational exit codes

[benw5483]

Summary

• An exec order that failed recorded that it failed and discarded why: order.failed carried the bare error (exit status 1) and an empty payload, and the run's tracking bead carried an outcome label and no text. Both now carry the resolved exec string, the exit status, and the last 2 KiB of the command's combined stdout/stderr, redacted through the same env redactor the dispatch logs use.
• Exec orders can declare success_exit_codes = [1]. Plenty of useful scripts reserve a low non-zero code for a finding rather than an error (a drift detector that exits 1 having already reported the drift), and recording every such run as a failure makes an order with a 100% failure rate indistinguishable from a healthy one.
• gc doctor's order-firing-current check read only order.fired, so an order firing exactly on schedule and failing every time reported green. It now reads order.completed and order.failed too, and reports last-succeeded beside last-fired.

What the record looks like now

bd show on a failed run's tracking bead:

exec: scripts/preflight.sh
exit status: 127
error: exit status 127
output (48 bytes):
scripts/preflight.sh: gc: unknown command "doctor"

gc doctor on an order that fires but doesn't succeed:

branch-protection: last fired 2h ago, expected every 24h
branch-protection: has never succeeded (last failed 2h ago)

Design notes for the reviewer

The doctor signal is advisory, not blocking. If it were blocking, a city that's been running a failing order for weeks would go red-gated the instant this check ships. Advisory still shows up in full in gc doctor output, and it won't wedge dispatch gates that read BlockingFailed. I left the existing fired-side severities alone.

An order with no recorded outcome stays silent. Its success state is unknown, not bad. So a city whose event history predates outcome recording won't light up red, and TestOrderFiringCurrent_NoOutcomeHistoryStaysSilent pins that.

A joined error refuses to yield an exit code. ExitCodeFromError returns (0, false) for an errors.Join, because a joined error carries a second failure (process-group cleanup, usually) alongside the exit status. Reducing it to the code alone would let a declared-informational code swallow that failure whole. Context cancellation isn't resolvable either, so a canceled run can't ever be read as a declared success.

Successful runs write nothing. A busy city carries tens of thousands of order-tracking beads, and a routine exit-0 run hasn't anything to diagnose, so that path skips the description write entirely.

Scope held deliberately. success_exit_codes lands on the order file only, not on [[orders.overrides]] in city.toml, which would pull the generated city schema and docs/reference/config.md into the diff. The order.failed payload stays NoPayload{} for the same reason: the detail rides in the event message rather than forcing a regenerated API client. Both look like reasonable follow-ups, but neither is needed to make a failed order diagnosable.

Test plan

• go test ./internal/orders/... ./internal/doctor/... ./test/docsync/... is green.
• go test ./cmd/gc/ gives 7827 pass, 37 fail. All 37 also fail on the base commit 89c9622 with an unmodified tree. They're a macOS /private/var vs /var symlink-resolution mismatch in the bd/dolt store-target tests, unrelated to this diff. One gotcha: the package needs -timeout 25m on a laptop. It runs about 23 minutes, and the default 10 looks like a hang.
• Each new behaviour was verified by injecting the defect it guards against and confirming the intended test goes red:
  • success guard accepts any non-zero exit → TestOrderDispatchExecUndeclaredExitStillFails fails
  • success guard refuses every declared code → TestOrderDispatchExecDeclaredInformationalExitCompletes fails
  • dispatch stops persisting the detail → all three detail tests fail
  • doctor's success classification disabled → TestOrderFiringCurrent_FiringButNeverSucceeding and TestClassifyOrderSucceeding fail

---

Generated by the operator's software factory.
• City: factory-main · Agent: local-core.builder-1
• On behalf of: @benw5483