[RFC]: Adopt AWS Lambda Powertools for observability (logging, metrics, tracing)

## Summary

Standardize backend observability with [AWS Lambda Powertools (TypeScript)](https://docs.powertools.aws.dev/lambda/typescript/latest/) — structured `Logger`, `Metrics` (EMF), and `Tracer` (X-Ray) — replacing the current ad-hoc `console.*` logging.

## Motivation

- ~90+ raw `console.log` / `console.error` / `console.warn` calls across the lambdas, with no structured fields or correlation IDs, making log search/correlation hard.
- No distributed tracing across the multi-hop flow: API Gateway → agents lambda → ECS pool-worker → mcp-server-graph → create-pr → GitHub/GitLab.
- No custom metrics for things worth tracking (agent-run durations, PR/MR creation success/skip/failure, GitLab token refreshes, per-provider usage).

## Alternatives considered

- Keep `console.*` logging as-is.
- Use OpenTelemetry / ADOT directly instead of Powertools.
- Adopt a structured-logging library without the full Powertools toolkit (no metrics/tracing helpers).

## Breaking changes

None user-facing. The CloudWatch log format would change (structured JSON), which could affect any external log-scraping or metric filters/alarms built on the current free-text logs.

## Open questions

- The lambdas are a mix of ESM (`github`, `gitlab`, `trackers`, …) and CJS (`create-pr`, `agents`, …) — confirm Powertools integration + esbuild bundling for both, and how much can be shared via `lambda/shared`.

---

_HTTP routing with the Powertools event handler is intentionally tracked separately as its own RFC._

Start by inventorying the roughly 90 console calls across the ESM and CJS lambdas, including agents, github, gitlab, trackers, and create-pr, and inspect what can be shared through lambda/shared. Confirm Powertools integration and esbuild bundling for both module styles. Done means a decided adoption plan covering structured logging, metrics, tracing, and compatibility concerns.

Written by the indexing model from the issue text.