Registration review rollout

All public signup types create only a player_register application. The response contains registration_id, not player_id. Correct credentials for pending or rejected applications return codes 20 or 21. Only approval creates a player.

Admin validates the human session and exact brand/agent scope before invoking the admin-only Player Service review command. A single transaction commits the member, referral, decision, PlayerRegistered event and durable Admin handoff. Repeating the same decision replays success; a conflicting decision fails. Historical applications already paired with a player require explicit reconciliation.

Admin reads the brand-scoped reward configuration and supplies a snapshot with the trusted review command. registration_audit_outbox stores that snapshot with the decision; a replay never changes it. Admin processes the coupon, message, duplicate-name tags, group count and audit log in one transaction with its receipt. The request attempts immediate processing; the worker retries pending jobs every ten seconds. Row locks prevent duplicates, and failures remain visible in worker health and logs. The job never writes wallet balances.

Deployment and rollback

1. Check pending duplicate accounts before migration 0079. It fails rather than deleting or rewriting application history.
2. Pause signup and approval with the normal maintenance controls during rollout. Apply the migration and deploy Player API/worker and Admin API/worker together. Publish the BO refresh change through its normal frontend release.
3. Verify pending -> denied login -> human approval -> successful login, rejection, scope enforcement and worker delivery; restore previous maintenance settings.

Do not roll back to auto-activating signup while registration is open. Drain pending effects before any infrastructure downgrade. Code rollback does not undo committed decisions or database changes. Other direct signup callers and test factories must perform approval before expecting a player_id.

Read-only reconciliation

Use the authorized environment's connection and schema search path. Missing approval history identifies a candidate for review, not proof of abuse. Operations must determine which accounts need re-review before changing state or sessions; this release does not retroactively approve, disable, or delete existing accounts. Keep any environment-specific export private.

SELECT brand_id, account, count(*)
FROM player_register WHERE status = 0
GROUP BY brand_id, account HAVING count(*) > 1;

SELECT p.guid, p.brand_id, p.agent_id, p.status, p.register_ts, p.platform
FROM player p
WHERE p.platform <> 'admin'
  AND NOT EXISTS (
    SELECT 1 FROM player_register r
    WHERE r.brand_id = p.brand_id AND r.account = p.account AND r.status IN (1, 2)
  )
ORDER BY p.brand_id, p.guid;

SELECT registration_id, brand_id, decision, reviewed_at
FROM registration_audit_outbox
WHERE processed_at IS NULL ORDER BY registration_id;