devboxes support (no API Key)

[scott-cotton]

Depends on signadot/go-sdk#75
And depends on https://github.com/signadot/signadot/pull/6388 for sandbox apply, local override, traffic record

stacked on #276

Summary

Adds devbox support for user authentication via bearer token

Key Changes

New Devbox Commands

• signadot devbox register - Register a new devbox with optional name and claim flags
• signadot devbox list - List devboxes (with --all flag to show all devboxes)
• signadot devbox delete - Delete a devbox (immediate deletion, no wait flags)

Devbox Session Management

• Session Manager (internal/devbox/session_manager.go) - Manages devbox session lifecycle with automatic renewal
• ID Persistence - Devbox IDs are cached locally in ~/.signadot/.devbox-id to avoid re-registration
• Bearer Token Support - Session manager works with bearer tokens. API Keys will require another api PR.
• Session Claiming - Support for claiming/releasing devbox sessions

Release Detection in Sandbox Manager

• Release Detection - The sandbox manager (sbmgr) monitors devbox session status and detects when a session is released by another process
• Deadend State - When release is detected, sbmgr enters a "deadend" state where it:
  • Shuts down the root manager (tunnel, localnet, etchosts)
  • Stops all active work (sandbox watcher, port forwarding, control plane proxy)
  • Keeps the gRPC server running so signadot local status can report the released state
  • Waits indefinitely until the process is killed externally
• Status Reporting - signadot local status displays devbox session health, including when a session has been released, showing the error reason and timestamp

Integration Updates

• Local Connect - Now automatically registers/retrieves devbox ID and session ID, passing them to locald
• Sandbox Apply - Updated to use devbox ID instead of machine ID for local sandboxes
• Local Override - Adapted to use devbox ID
• Traffic Record - Updated to include devbox ID in instrumentation

Protocol & Status Updates

• Added DevboxSessionStatus proto message with health, release status, and error tracking
• Updated sandbox manager to monitor devbox session status and detect session releases
• Added released detection plumbing in sandbox manager

Configuration

• New Devbox config struct with sub-configs for list, register, and delete commands
• ConnectInvocationConfig now includes DevboxID and DevboxSessionID fields

Technical Details

• 30 files changed: 2,415 insertions(+), 407 deletions(-)
• Devbox registration uses machine ID and hostname and optional user provided name to replace the hostname for identification
• Session manager handles auth token refresh automatically
• shouldn't break anything other than local workloads/connect with API Key. but needs more thorough testing.
• Release detection occurs during session renewal attempts - if the session ID no longer matches or the session is not found, sbmgr detects the release and enters deadend state

Testing Notes

• Devbox commands require API access for registration/listing/deletion via bearer token
• Session management works with bearer token authentication
• signadot local status shows devbox session status including release detection
• When a devbox session is released, sbmgr gracefully shuts down active components while maintaining status reporting capability
• sandbox apply creates an associated sandbox which is subsequently connected to the local connect session.
• registration with --name does not overwrite ~/.signadot/.devbox-id but does create a new devbox
• devbox list
• devbox delete (also when .devbox-id is contains the devbox id)
• local connect with and without .devbox-id and with and without --name

Known TODOS

Aside from API Key support, this requires some additional cleanup of the grpc protos -- removing RegisterSandbox.
Another round of sdk update for labels vs idmeta to be ironed out in a subsequent iteration.

[daniel-de-vera]

Why can't we use the normal API client and we need a custom one? (note that we do auth refresh in the regular one)

[scott-cotton]

1. The normal API client only refreshes tokens for KeyringAuthSource (line 94 in api.go), not PlainTextAuthSource, even
   though refreshKeyringAuth() supports both.
2. The normal API client requires OrgName upfront (line 85-87), which may not be available initially.
3. The normal API client doesn't support fallback to ciConfig.APIKey.

this was put in devbox pkg to isolate the changes without introducing a new refactoring.

[scott-cotton]

probably should refactor to fix the bug in the original in 1...

[daniel-de-vera]

If you want to do that later on a separate PR, I'm fine with it.

[daniel-de-vera]

LGTM