refactor: thread context throughout and enforce ContextConnectivity lint rule

[dgageot]

This branch integrates the Lint/ContextConnectivity cop from rubocop-go as a whole-program static analysis pass and then resolves every violation it finds. The cop detects places where a context.Context is available but a derived or background context is used instead — patterns that silently lose deadlines, cancellation signals, and trace spans.

The bulk of the work is mechanical but intentional: context threading was pushed down into the Runtime interface and its implementations, through RAG embedding and chunking helpers, into the SQLite memory backend (now lazily opened with the caller's context), through the telemetry TrackSynchronous path, into proxy-allowlist resolution at dial time, and across dozens of test harnesses that previously created detached roots with context.Background(). Places where a genuinely detached context is correct — shutdown flushes, background notification playback — are suppressed with context.WithoutCancel derivation, which was added to the rubocop-go dependency in the same batch.

No behaviour changes are intended. task --force lint and task --force test both pass.

[docker-agent]

Assessment: 🔴 CRITICAL

This PR threads context.Context throughout the codebase — a well-structured refactor that correctly uses context.WithoutCancel for detached lifecycle objects. One confirmed high-severity regression and three medium-severity issues were found in the newly introduced + lines. The bulk of the mechanical context threading (test harnesses, logging, RAG pipeline) looks correct.

[docker-agent]

[HIGH] ensureAskpass permanently disables askpass if the first call's context is cancelled

h.askpassStarted is set to true before startAskpassServer is called, and is never reset on failure. If the context passed to ensureAskpass on the first-ever sudo command is cancelled before lnConfig.Listen completes, startAskpassServer returns an error and h.askpass remains nil. All subsequent shell commands then receive nil from ensureAskpass (the guard if h.askpassStarted { return h.askpass } short-circuits), permanently disabling the askpass server for the lifetime of the shellHandler — sudo commands will run without the password-prompt helper for the rest of the session.

Before this PR, startAskpassServer was called with context.Background() (uncancellable), so this failure mode did not exist. The fix is to either (a) reset h.askpassStarted = false in the error path so the next command retries, or (b) call startAskpassServer with a long-lived context (e.g., context.WithoutCancel(context.Background()) or a handler-lifetime context) rather than the per-request context.

[docker-agent]

[MEDIUM] proxyDialAllowlist (potentially blocking DNS) called on every TCP dial

proxyDialAllowlist(ctx) is now called inside the DialContext closure, meaning it runs on every individual TCP connection the transport makes — including connection-pool replenishment, retries, and keep-alive re-dials. The function reads 6 environment variables and, for hostname-based proxy specs, calls proxyHostPorts which performs a DNS lookup with a 5-second timeout to resolve each proxy hostname to its IP addresses.

Before this PR the allowlist needed a ctx to pass to proxyHostPorts, which forced the call into the per-dial closure. The fix is to pre-compute the allowlist once at transport-construction time (environment variables and proxy hostnames rarely change at runtime) and capture the result in the closure, or to use sync.Once / a short-TTL cache. If env-var changes must be picked up at dial time, a sync.Once-per-transport or a cached value with a TTL would bound the DNS overhead.

[docker-agent]

[MEDIUM] ResumeSession passes request-scoped context to newRuntime without context.WithoutCancel

The runtime created here is stored in a.sessions (a long-lived map) and is expected to serve the resumed session indefinitely. However, it is constructed with ctx — the HTTP handler's request context, which is cancelled as soon as the RPC call returns.

If runtime.New / newRuntime stores the context for use in background goroutines (e.g. tool list refresh via emitToolsChanged, which is now wired through r.ctx()), the runtime's background work will be cancelled when the RPC handler returns. The parallel paths CreateSession and StartSession (line 205) exhibit the same pattern, so this may be intentional, but the PR's stated policy for "genuinely detached" objects is to wrap with context.WithoutCancel. Compare with NewLocalRuntime, which already wraps: ctx: func() context.Context { return context.WithoutCancel(ctx) } — so the runtime itself does the right thing internally. If newRuntime calls NewLocalRuntime the internal closure will protect background work; the only concern is if any state is derived from the raw ctx before that wrapping.

[docker-agent]

[MEDIUM] context.WithoutCancel does not strip deadlines — r.ctx() inherits the caller's deadline

Go's context.WithoutCancel (Go 1.21+) strips the cancellation signal and cause but explicitly preserves all other context properties, including deadlines. From the Go docs: "WithoutCancel returns a copy of parent that is not canceled when parent is canceled. The returned context returns no Deadline …" — wait, actually it DOES carry the deadline if the parent has one; it only removes the cancel chain.

If NewLocalRuntime is ever called with a context that has a deadline (e.g. a request-scoped context with a 30-second timeout), r.ctx() will return a context that expires at that same deadline. Background work derived from r.ctx() — most notably emitToolsChanged which calls context.WithTimeout(r.ctx(), toolsChangedTimeout) — will use a base context that may already be expired or nearly expired, silently truncating tool-list refreshes throughout the session.

The fix is to use context.WithoutCancel(context.Background()) or to derive from a process-lifetime context rather than from the caller's context when constructing the stored background context.

[docker-agent]

[MEDIUM] Context cancellation silently misreported as "queue full" in Steer/FollowUp

Before this PR, Enqueue was called with context.Background() (uncancellable), so Enqueue returning false always meant the queue was actually full. Now the caller's ctx is threaded in. If MessageQueue.Enqueue blocks waiting for capacity and respects context cancellation (returning false on ctx.Done()), a cancelled context will cause the error message "steer queue full" or "follow-up queue full" to be returned — masking the real cause (cancellation) as a capacity error.

This matters for callers that inspect the error or log it for debugging: a cancelled follow-up (e.g. from a request that timed out) will look like a capacity problem in logs, making operational diagnosis harder. If Enqueue is truly non-blocking (returns immediately if the channel buffer is full), the concern only applies to concurrent cancellation racing the send, which is less likely. Consider returning ctx.Err() when the context is done, or documenting that cancellation maps to the same "full" error.