Route settings page in the portal: tracing and recording toggles

[07prajwal2000]

Why

routes.tracing_enabled and routes.record_execution exist in the database, are
returned by GET /v1/:projectId/routes/:id, and are accepted by the partial
update endpoint. Nothing in apps/portal can set either one. A project can
now pick its telemetry destinations (project settings → Telemetry, #195), but
every route still ships with both switches off and no way to turn them on
outside SQL or a raw API call.

The new portal has no route settings page at all — apps/portal/src/routes/_authed/$projectId/routes.tsx
lists routes and creates them, and that is the whole surface.

What

A route settings page (or panel) in apps/portal exposing what the route row
already carries:

• Tracing — exports spans to the project's own OTEL destination, stores
  nothing on our side.
• Recording — persists a debug recording for the trace viewer. Expensive, so
  it stays off by default. The viewer and its endpoints are a separate issue.
• Route timeout (timeoutSeconds), currently only settable at create time.
• Active/inactive.

The two telemetry switches are deliberately independent and the UI must not
merge them into one: tracing is "send it to your backend", recording is "keep it
in ours".

Notes

• The write path already exists: PATCH /v1/:projectId/routes/:id
  (apps/server/src/api/v1/routes/update-partial) accepts tracingEnabled,
  recordExecution, timeoutSeconds and active. No server work should be
  needed for this issue.
• Editing either flag triggers a recompile — both are stamped into the route
  artifact by the compiler, so the toggle must not be treated as cosmetic.
• Tracing with no project traces destination set produces no spans. The page
  should say so and link to project settings rather than silently doing nothing.

Depends on #195 for the destination side. Recording's storage and list endpoints
are tracked separately.