fix: keep the /api prefix when proxying /api/logs/*

[a-effort]

Problem

GET /api/logs/activity fails through the BFF. The catch-all proxy strips its own /api before forwarding, on the assumption (stated in the file) that mcpgateway mounts every router at the root:

// Wildcard capture excludes the leading '/api/'; FastAPI routes are
// mounted at root, so reattach a single leading slash.

log_search declares prefix="/api/logs", so /api/logs/activity was forwarded to /logs/activity upstream and 404d.

Probed against a live gateway:

path	result
/api/logs/activity	401, route exists and needs auth
/logs/activity	404
/api/definitely-not-a-real-route	404, so the 401 above is meaningful

Why now

No caller had ever exercised an /api/logs/* route through the BFF. The other five log routes exist only as generated URL builders in contextForge.ts with no live callers, so the root-mount assumption was never tested. It surfaced the moment the Recent Activity feed asked for real data.

Fix

A toUpstreamPath() helper that keeps the prefix for logs/* and strips it for everything else, plus a correction to the now-false comment.

The exception is deliberately narrow. /api/logs is the only router in mcpgateway mounted under /api. The other 29 sit at the root or under root-relative prefixes (/v1/..., /admin/..., /observability/...) that already proxy correctly. That's recorded next to the constant so it doesn't get "simplified" back.

Tests

Two additions to server/test/proxy.test.ts: /api/logs/activity reaches upstream intact, and /api/logsearch still strips. The second guards the prefix match, since startsWith("logs") without the trailing slash would wrongly catch it.

BFF suite: 79 passed / 8 files. Server typecheck, eslint and prettier clean.