perf(pam launch): cache TunnelDAG across the launch flow

[idimov-keeper]

Previously _get_launch_credential_uid was called three times per launch — once in launch.execute and twice inside extract_terminal_settings — and each call built a fresh TunnelDAG (2-3 HTTP round-trips each). find_gateway also re-resolved the config UID via get_config_uid_from_record.

Build the TunnelDAG once in execute() and thread it through:

• _get_launch_credential_uid(params, record_uid, tdag=...) reuses the caller's DAG when provided.
• find_gateway(params, record_uid, tdag=...) reads config_uid from tdag.record.record_uid and uses the new _gateway_uid_from_config helper to skip the redundant get_leafs roundtrip.
• extract_terminal_settings(..., dag_linked_uid=...) takes a pre-resolved value via a _DAG_UID_UNSET sentinel (None is a valid resolved result) and drops both inline DAG lookups.

Add a PamConnectTiming framework (new connect_timing.py) gated by PAM_CONNECT_TIMING=1 and instrument the full launch:

• pam-launch:execute — pre-phase checkpoints through gateway resolution (previously invisible).
• pam-launch:terminal_connection / pam-launch:webrtc-tunnel — existing phase boundaries around tunnel open.
• pam-launch:cli_session — checkpoints through guac ready.
• pam-launch:total — grand-total wall clock from command entry to input_handler.start().

Verified against QA: grand total ready_for_prompt drops from ~17.0s to ~12.4s (~4.6s saved). A single Found launch credential via DAG log line per launch (was three).