refactor(backend): remove `(app as any).authenticate` fallback chains from remaining route files

[yachikadev]

Summary

Remove the unsafe (app as any).authenticate fallback chains still present in cards.ts, event.ts, nfc.ts, and connect.ts, and replace them with the typed app.authenticate decorator — same pattern just applied to team.ts in #581 (closes #554).

Contexts

In #581, team.ts was refactored to remove all any usages and replace the manual auth fallback chain with a properly typed app.authenticate decorator (typed via the @fastify/jwt + Fastify augmentation in src/types/fastify.d.ts).

The same unsafe pattern still exists in several other route files:

if (typeof (app as any).authenticate === 'function') {
  await (app as any).authenticate(request, reply);
  return;
}

and in a few places, an additional request.server as any fallback layered on top. This was flagged as a follow-up during review on #581 so the cleanup can go repo-wide instead of being one-off.

Tasks

• Replace (app as any).authenticate / request.server as any fallback chains with preHandler: [app.authenticate] in src/routes/cards.ts
• Same cleanup in src/routes/event.ts
• Same cleanup in src/routes/nfc.ts
• Same cleanup in src/routes/connect.ts
• Remove the now-redundant manual request.jwtVerify() try/catch in each preHandler (the decorator already handles 401 on failure)
• Update corresponding test files so app.authenticate is decorated inside buildApp() before app.register(...) (Fastify resolves preHandler during app.ready())

Acceptance Criteria

• No (app as any) or request.server as any remains in the 4 files above
• All routes use preHandler: [app.authenticate] consistently, no .bind(app) needed
• tsc --noEmit passes with 0 errors
• ESLint clean on all touched files
• Existing test suites for these route files pass (only setup/decorator wiring should change, not test expectations)

Area

backend

Difficulty

Easy / Good first issue — pattern is already established and proven in #581, mostly mechanical repetition across 4 files.

[github-actions]

Hi @yachikadev,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[yachikadev]

/backend

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[yachikadev]

Hi @Harxhit, I'd like to work on this issue under GSSoC.

I'm already familiar with this exact pattern since I implemented the team.ts version of this fix in #581 — replacing the (app as any).authenticate / request.server as any fallback chains with the typed app.authenticate decorator, and wiring up the decorator correctly in the test setup (buildApp() before app.register(...), since Fastify resolves preHandler arrays during app.ready()).

Plan:

1. Apply the same cleanup to cards.ts, event.ts, nfc.ts, and connect.ts — swap the manual fallback chains for preHandler: [app.authenticate], no .bind(app) needed since the decorator doesn't use this.
2. Remove the redundant manual jwtVerify() try/catch in each preHandler (decorator already returns 401 on failure).
3. Update/verify the corresponding test files decorate app.authenticate in buildApp() before route registration, so the suites don't break the way team.test.ts initially did in fix: improve type safety in team.ts, remove any usages (closes #554) #581.
4. Verify with tsc --noEmit, eslint, and vitest run on each touched file before opening the PR.

Since the pattern and the fix are already proven in #581, this should be a fairly quick, low-risk cleanup. Please assign this to me — happy to get started right away.

[Harxhit]

@yachikadev I have assigned this issue to you.