[RFC]: Adopt AWS Lambda Powertools event handler for HTTP routing

## Summary

Replace the hand-rolled `httpMethod` / `path` routing in the API lambdas with the [AWS Lambda Powertools event handler / router](https://docs.powertools.aws.dev/lambda/typescript/latest/core/event-handler/).

## Motivation

- Several lambdas (`agents`, `trackers`, `github`, `gitlab`) dispatch requests via manual chains like `httpMethod === 'GET' && path.endsWith('/...')` and `path.match(/.../)`.
- A declarative router reduces boilerplate, centralizes path-parameter parsing, and lowers the chance of subtle route-matching bugs (ordering, prefix collisions, CloudFront stage-prefix handling).

## Alternatives considered

- Keep the manual `httpMethod`/`path` routing as-is.
- Adopt a lightweight standalone router library instead of Powertools.

## Breaking changes

Internal only — no change to the external API surface if existing routes are mapped 1:1.

## Open questions

- Higher-churn migration that touches every route in the affected lambdas — is it worth doing, or is manual routing acceptable to keep?
- The lambdas are a mix of ESM and CJS — confirm event-handler ergonomics and esbuild bundling for both.

---

_Observability (Logger / Metrics / Tracer) is intentionally tracked separately: #281._

Start by locating the agents, trackers, github, and gitlab API lambdas and their manual httpMethod/path dispatch chains. Read the AWS Lambda Powertools event-handler documentation, then verify routing and esbuild behavior for both ESM and CJS lambdas. Done means every existing route is mapped 1:1 without external API changes and the migration works in both module formats.

Written by the indexing model from the issue text.