adventure: work the five review findings the last pass left open

The extract pre-check is gone. It read a snapshot up to two minutes behind and
still got the last word, so somebody who set out over Matrix during a lagging
roster push was told they weren't on an expedition for a run gogobee would
happily have ended. Same call abandon and leave already made: let it through and
let rejected_not_running be the answer.

The siege_join check stays, because whether a boss is camped outside town is
town-wide and runs on a day-or-longer clock, but it now reads one column through
SiegeIsCamped instead of loading every defender row and the whole history to
look at one flag.

The war-room history insert is OR REPLACE. boss_id is the primary key and it was
never settled whether gogobee means the siege instance or the boss type by it, so
a duplicate pair used to fail the transaction carrying the live boss and the
muster too and freeze the war room on the last good snapshot. A dropped history
row is the smaller failure; the open question is noted in the schema.

offersToUndo's guard didn't cover the case its comment claimed. A gogobee too old
to push seats sends a valid blob with no party key, which decodes to the same
empty slice as a solo run, and a party member got shown the button that throws
away everyone's day. That needs a new field, so whoDetail gains party_known and
the flag gates the empty-list branch alone; the branch that reads the viewer's
own seat is self-evidencing and keeps working against any sender. gogobee's half
is written up in adventure_party_known_flag.md.

And an empty offer list no longer claims "you're already out there", which Pete
can't actually know from a game box too old to push offers at all.

internal/web/siege_test.go

@@ -236,6 +236,37 @@ func TestSiegeHistoryRendersEndedBar(t *testing.T) {
 	}
 }
 
+// TestSiegeHistoryCollisionDoesNotFreezeTheWarRoom. boss_id is the history's
+// primary key and it is not settled whether gogobee means the siege instance or
+// the boss type by it, so two rows can arrive sharing one. Under a bare INSERT
+// that failed the transaction carrying the live boss and the muster too, and the
+// war room stopped moving on the last good snapshot with nothing to say why. The
+// ingest has to degrade to a lost history row instead.
+func TestSiegeHistoryCollisionDoesNotFreezeTheWarRoom(t *testing.T) {
+	s, _ := newAdvServer(t, "tok")
+	now := time.Now().Unix()
+
+	push := liveSiege(now, 650)
+	push.Siege.History = []storage.SiegePast{
+		{BossID: 3, BossName: "The Ashen Wyrm", Tier: 5, Outcome: "survived",
+			HPRemaining: 300, HPMax: 1200, Defenders: 3, EndedAt: now - 86400},
+		{BossID: 3, BossName: "The Ashen Wyrm", Tier: 5, Outcome: "defeated",
+			HPRemaining: 0, HPMax: 1200, Defenders: 6, EndedAt: now - 30*86400},
+	}
+	if w := postSiege(t, s, "tok", push); w.Code != 200 {
+		t.Fatalf("push with a duplicated boss_id = %d, want 200 (%s)", w.Code, w.Body.String())
+	}
+
+	v := s.siege()
+	if !v.Active || v.HPCurrent != 650 {
+		t.Fatalf("war room = active %v at %d hp, want the pushed live boss — the collision took the whole push down",
+			v.Active, v.HPCurrent)
+	}
+	if len(v.History) != 1 {
+		t.Errorf("history = %d rows, want 1 (the last of the colliding pair)", len(v.History))
+	}
+}
+
 // TestSiegeAPIFeedsTheBar. The bar only moves because this endpoint answers, so
 // the field names it emits are load-bearing: the page's JS reads hp_percent to
 // set the width and active to decide whether to keep polling at all.