perf: parallelize sequential DB queries in adminStats and getCompletionPercentage

[claude]

Two tRPC procedures execute independent database queries sequentially instead of in parallel with Promise.all. Each pair has no data dependency and can run concurrently to reduce latency.

Affected Locations

1. challenge.adminStats — server/api/routers/challenge.ts lines 256–289

// Currently sequential (two round-trips):
const [submissionStats] = await ctx.db.select(...).from(userSubmission);
const [progressStats]   = await ctx.db.select(...).from(userProgress);

// Fix — parallel:
const [[submissionStats], [progressStats]] = await Promise.all([
  ctx.db.select(...).from(userSubmission),
  ctx.db.select(...).from(userProgress),
]);

2. userProgress.getCompletionPercentage — server/api/routers/userProgress.ts lines 94–113

// Currently sequential (two round-trips):
const [totalResult]     = await ctx.db.select({ count: count() }).from(challenge).where(themeFilter);
const [completedResult] = await completedQuery;

// Fix — parallel:
const [[totalResult], [completedResult]] = await Promise.all([
  ctx.db.select({ count: count() }).from(challenge).where(themeFilter),
  completedQuery,
]);

Impact

Each sequential pair adds one extra database round-trip per request. With Neon serverless, individual query latency is 5–30ms, so parallelizing saves that overhead on every call to these endpoints.

Notes

The codebase already applies this pattern in other procedures — getStatus in onboarding was parallelized in e364ea7. This is a continuation of that work.