adventure: don't strand an order on a database blip, don't misroute a tap

Two things a code review turned up in the W9 seams.

The verdict handler answered 400 for everything ResolveAdvOrder could fail
with, not just a bad verdict. gogobee's contract says a 400 means "park this
row for a human", so a SQLite busy or a disk hiccup permanently stranded an
extract or a bout that was perfectly resolvable. Split the two apart with
ErrBadAdvVerdict: a verdict outside the terminal set is still 400, because
gogobee will never send it successfully, and a genuine storage failure is now
500 and comes back on the next poll.

The push URL builders concatenated the guid and the run id raw, while every
other builder beside them path-escapes because these values arrive over a wire.
A guid carrying a slash sent the notification tap to a different page.

internal/storage/orders.go

@@ -148,6 +148,12 @@ func validAdvVerdict(status string) bool {
 
 var ErrNoSuchAdvOrder = errors.New("orders: no such order")
 
+// ErrBadAdvVerdict is a verdict outside the terminal set. It is kept distinct
+// from a storage failure so the web seam can answer 400 (gogobee sent something
+// it will never be able to send successfully) rather than parking a perfectly
+// resolvable order on a transient database error.
+var ErrBadAdvVerdict = errors.New("orders: bad verdict")
+
 // InsertAdvOrder records a fresh, pending order and returns it with a new guid.
 // The guid is minted here so the owner has a stable reference the instant they
 // click, before gogobee has heard of it. The caller has already proved the signed-
@@ -218,7 +224,7 @@ func PendingAdvOrders(limit int) ([]AdvOrder, error) {
 // missing row all take one path.
 func ResolveAdvOrder(guid, status, detail string) (AdvOrder, error) {
 	if !validAdvVerdict(status) {
-		return AdvOrder{}, fmt.Errorf("orders: bad verdict %q", status)
+		return AdvOrder{}, fmt.Errorf("%w %q", ErrBadAdvVerdict, status)
 	}
 	now := nowUnix()
 	if _, err := Get().Exec(