adventure: tell a player what happened while they were away

The site could only reach somebody who was already looking at it. Push
existed and adventure used none of it, so the one communal event in the
game -- the Siege -- was invisible to anyone not sitting in Matrix, and a
player whose adventurer died found out whenever they next opened a tab.

Four opt-in categories, every one of them off until asked for: the Siege
(realm-wide, begins and ends), your expedition ending, your adventurer
wandering off, and a contract landing on you. Turning on news
notifications is not consent to be told about the game, so nothing here
enrolls anybody automatically.

No new wire. Every trigger is a dispatch already landing in
adventure_events, so this is Pete-side only and gogobee is untouched.

Two things it needed from storage. push_subscriptions now keeps the
Matrix localpart alongside the OIDC subject, because every ownership
join in the schema is keyed on the localpart and the sender runs on a
ticker with no session to read one from -- without it there is no way to
answer "whose adventurer is this". And the alerts carry their own
watermark, kept apart from the digest's: the two run on different clocks
and one column would let each consume the other's backlog.

The ownership join is re-read on every pass rather than trusted from the
subscription row, so an opt-out or a removal closes the channel at once.
It fails closed in both directions, and an unresolved owner can never
fall through to a broadcast -- a game alert naming somebody's adventurer,
delivered to the wrong phone, is a privacy leak dressed as a feature.

An existing subscription carries watermark 0, which read literally means
"has never been told anything" and would page every subscriber for the
whole history of the realm on the first tick after deploy. Those rows are
stamped to now and start from the next dispatch.

Verified against a running Pete with a real push service, real P-256
client keys and real encryption: the right person is notified, the wrong
one is not, a second pass is silent, and dropping the player from the
board takes the channel with it.

Claude-Session: https://claude.ai/code/session_012bxpQQJDjC1mTtLN3VVtBQ

internal/storage/push_test.go

@@ -5,15 +5,15 @@ import "testing"
 func TestPushSubscriptionLifecycle(t *testing.T) {
 	setupTestDB(t)
 
-	if err := AddPushSubscription("sub-1", "https://push.example/ep-a", "p256-a", "auth-a"); err != nil {
+	if err := AddPushSubscription("sub-1", "josie", "https://push.example/ep-a", "p256-a", "auth-a"); err != nil {
 		t.Fatal(err)
 	}
 	// A second endpoint for the same user (e.g. a second device).
-	if err := AddPushSubscription("sub-1", "https://push.example/ep-b", "p256-b", "auth-b"); err != nil {
+	if err := AddPushSubscription("sub-1", "josie", "https://push.example/ep-b", "p256-b", "auth-b"); err != nil {
 		t.Fatal(err)
 	}
 	// A different user.
-	if err := AddPushSubscription("sub-2", "https://push.example/ep-c", "p256-c", "auth-c"); err != nil {
+	if err := AddPushSubscription("sub-2", "quack", "https://push.example/ep-c", "p256-c", "auth-c"); err != nil {
 		t.Fatal(err)
 	}
 
@@ -26,7 +26,7 @@ func TestPushSubscriptionLifecycle(t *testing.T) {
 	}
 
 	// Re-subscribing the same endpoint updates keys in place, not a new row.
-	if err := AddPushSubscription("sub-1", "https://push.example/ep-a", "p256-a2", "auth-a2"); err != nil {
+	if err := AddPushSubscription("sub-1", "josie", "https://push.example/ep-a", "p256-a2", "auth-a2"); err != nil {
 		t.Fatal(err)
 	}
 	subs, _ = ListPushSubscriptions()
@@ -54,7 +54,7 @@ func TestPushSubscriptionLifecycle(t *testing.T) {
 
 func TestTouchPushSubscriptionAdvancesWatermark(t *testing.T) {
 	setupTestDB(t)
-	if err := AddPushSubscription("sub-1", "https://push.example/ep", "p", "a"); err != nil {
+	if err := AddPushSubscription("sub-1", "josie", "https://push.example/ep", "p", "a"); err != nil {
 		t.Fatal(err)
 	}
 	subs, _ := ListPushSubscriptions()