fix(auth): use auth_user_id instead of id when querying users table in backup-pin

authenticateUser() returns the Supabase Auth user object whose .id is the UUID
from auth.users (the Supabase Auth internal table). The application's public
'users' table has its own primary key 'id' and links to Auth via 'auth_user_id'.

The original code queried .eq('id', user.id) which compared the Auth UUID against
the internal PK — a different UUID — so no row was ever matched.

Result of the bug:
- GET /api/auth/backup-pin always returned { hasPin: false } for every user
  because .single() got PGRST116 (no rows found) and the code treated missing
  row as 'no PIN set'.
- POST /api/auth/backup-pin silently succeeded (UPDATE matched 0 rows) but the
  PIN hash was never persisted, leaving the backup PIN feature entirely broken.

Fix: replace both .eq('id', user.id) calls with .eq('auth_user_id', user.id).

Severity: HIGH — backup PIN feature completely non-functional

Author: katnisscalls99

src/app/api/auth/backup-pin/route.js

@@ -110,7 +110,7 @@ export async function GET(request) {
 		const { data, error } = await getServiceRoleClient()
 			.from('users')
 			.select('backup_pin_hash')
-			.eq('id', user.id)
+			.eq('auth_user_id', user.id)
 			.single();
 
 		if (error) {
@@ -151,7 +151,7 @@ export async function POST(request) {
 		const { error } = await getServiceRoleClient()
 			.from('users')
 			.update({ backup_pin_hash: pinHash })
-			.eq('id', user.id);
+			.eq('auth_user_id', user.id);
 
 		if (error) {
 			console.error('Error setting backup PIN:', error);