fix(server): gate proposal participant timeout on actual expiry

ProposalParticipantExpireSQL marked every PENDING participant on a
proposal TIMED_OUT unconditionally -- it took a proposal_id and 'now'
but never actually compared 'now' against the proposal's expires_at,
unlike its sibling ProposalExpireSQL (which does gate on
'expires_at <= $2'). Both GetProposal and RespondToProposal run this
statement on every call as a recovery step, so the very first
RespondToProposal for any proposal timed out every participant
(including the one about to respond) before checking their response,
then rejected the real accept/decline with ErrConflict. Add the same
expiry gate via an EXISTS against proposals.expires_at, matching
ProposalExpireSQL's own condition, and update the SQL-fragment test to
assert the gate is present. Verified end to end against a real
PostgreSQL instance: TestPostgreSQLProposalClaimAndResponseAreAtomic
now passes a two-participant accept/accept sequence that previously
failed on the first response.

server/store/proposal_recovery_sql_test.go

@@ -8,7 +8,7 @@ import (
 func TestProposalRecoverySQLBindsParticipantAndExpiresAtReadBoundary(t *testing.T) {
 	for query, fragments := range map[string][]string{
 		ProposalExpireSQL:                    {"state = 'OPEN'", "expires_at <= $2", "revision = revision + 1"},
-		ProposalParticipantExpireSQL:         {"response = 'PENDING'", "response = 'TIMED_OUT'"},
+		ProposalParticipantExpireSQL:         {"response = 'PENDING'", "response = 'TIMED_OUT'", "proposals.expires_at <= $2"},
 		ProposalRecoverySelectSQL:            {"proposal_id = $1", "player_id = $2", "EXISTS"},
 		ProposalParticipantsSelectSQL:        {"proposal_id = $1", "ORDER BY player_id"},
 		ProposalResponseIdempotencyInsertSQL: {"ON CONFLICT (scope, idempotency_key) DO NOTHING", "payload_digest"},