N3/P6b: a party you can actually ask someone to join

!expedition invite / accept / decline / party / leave. The invitee buys
their own loadout and it pools -- a party is a shared burden, not a free
ride.

The plan said invites close "before the first walk". That is not a window,
it is a race: autoRunMinExpeditionAge leaves a fresh expedition alone for
thirty minutes and then the autopilot starts walking it, and the leader's
own !expedition run can beat it there. Thirty minutes is not enough to ask
a friend who is asleep.

So two changes to what the plan specified:

- The window is all of Day 1, not the first step. Supplies burn at the
  night rollover, so a companion who arrives three rooms in pays and
  receives exactly what one who arrived at the gate does.
- An unanswered invite pins the autopilot: loadExpeditionsForAutoRun skips
  any expedition somebody has been asked to join. The leader must not be
  dragged into a boss room while their friend reads the DM. Bounded by
  expeditionInviteTTL (2h) in the query itself, so a forgotten invite
  costs an afternoon, not the expedition.

New table expedition_invite. Absent == nobody was asked, which is true of
every expedition predating N3 -- nothing to backfill, same reading that
let expedition_party and roster_size ship without one.

Details worth keeping:

- Outstanding invites count against expeditionPartyMax. Otherwise a leader
  asks four people and three accept.
- Pooling raises Current *and* Max. supplyDepletion reads the ratio, so
  folding in only Current would read as the party suddenly starving.
- A member's supplies stay in the pool when they !leave. They were spent
  on the expedition, not lent to it; clawing them back would let someone
  starve the party on their way out.
- assertNotAdventuring guards expeditions and rosters but not bare zone
  runs, so accept checks getActiveZoneRun itself -- startExpedition does.
- A party is not a taxi: zoneOpenToLevel gates the invitee on the same
  tier rule !expedition start applies to the leader.
- releaseParty now clears invites too, or someone could accept onto a
  corpse.
- expeditionCmdStatus and the bare `!expedition` switched to
  activeExpeditionFor, and a member typing `!expedition go 2` is told the
  leader picks the path instead of falling through to `start` and being
  told "2" is an unknown zone.

Combat still seats one player -- handleFightCmd is P6c. go test ./...
green, golden byte-identical.

internal/db/db.go

@@ -2142,6 +2142,28 @@ CREATE TABLE IF NOT EXISTS expedition_party (
 );
 CREATE INDEX IF NOT EXISTS idx_expedition_party_user
     ON expedition_party(user_id);
+
+-- ── N3/P6b — pending party invites ────────────────────────────────────────
+-- An invite the leader has sent and the invitee has not yet answered. It is
+-- deleted on accept, on decline, and when the expedition ends; it expires on
+-- read past expeditionInviteTTL, so a forgotten invite cannot pin an
+-- expedition's autopilot forever.
+--
+-- Absent == nobody has been asked, which is true of every expedition that
+-- existed before N3, so there is nothing to backfill.
+--
+-- While any row here names an expedition, the autopilot will not walk it: the
+-- leader must not be dragged into a boss room while their friend is still
+-- reading the invite DM.
+CREATE TABLE IF NOT EXISTS expedition_invite (
+    expedition_id   TEXT NOT NULL,
+    user_id         TEXT NOT NULL,
+    invited_by      TEXT NOT NULL,
+    invited_at      DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    PRIMARY KEY (expedition_id, user_id)
+);
+CREATE INDEX IF NOT EXISTS idx_expedition_invite_user
+    ON expedition_invite(user_id);
 `
 
 // SeedSchedulerDefaults inserts default scheduler jobs if they don't exist.