feat: add status watcher to MCP server

[code-asher]

This is meant to complement the existing task reporter since the LLM does not call it reliably.

I also did some refactoring to use the common agent flags/env vars, those changes are in separate commits.

For #18163, but will need to update the modules to make use of it.

[hugodutka]

Idea for getting rid of that "a message from the screen watcher and a message from the LLM could arrive out of order if the timing is just right" race condition:

• maintain a state object that keeps track of
  • an array of pending updates with timestamps
  • the latest status reported to the server with a timestamp
• instead of submitting status updates to a queue, push them to the array of pending updates
• in a separate loop that ticks every second, process pending updates in batch. when processing a "screen stable" update, act on it only if it's at least 1 second old and there hasn't been a "screen changing" update after it. leave it in the pending array if it's not old enough and there hasn't been a "screen changing" update after it.
• keep the existing deduplication logic that takes into account conversation length and latest status

up to you if you want to implement it. I'm fine with merging the current version once you address the feedback

[hugodutka]

I'd expect the names to be swapped: tryCreateAgentClient should return an error, createAgentClient should not. "try" implies the possibility of failure.

[code-asher]

Very fair. For this though I just mirrored TryInitClient. I think the logic is that try here is more like attempt, in the sense that failing is OK, or maybe in the way that try in try/catch suppresses errors. Happy to rename it, but maybe we should rename both if we do.

[hugodutka]

Renaming both would be perfect.

[code-asher]

I force pushed to break out the UI fix but the remaining commits are unchanged.

Then I moved the update predicates to the push phase instead of the pop phase, so now if we are waiting on coderd, we will not queue up a bunch of duplicate updates that will just end up getting discarded later anyway. Now they get discarded immediately.

This could still use channels, I would just need a mutex over lastReport/lastMessageID. But, although I know we are unlikely to hit the limit I do still like that the queue can drop the oldest update.

I am also doing the part where we keep the last summary from the agent during the push phase instead, which is nice because now even if an agent update is dropped while waiting on coderd because the queue got too big we can still log it with the next agentapi status update. Granted, with a buffer of 512 this is probably not going to actually happen.

[hugodutka]

That's awesome. I set it up in a local deployment and it works! Both for reporting status if the ai agent doesn't, and for completing statuses the ai agent didn't.

Minor nits on naming: I believe it's more accurate to refer to claude code and others as "AI Agents" rather than LLMs. Also, whenever referring to the url of a coder/agentapi process, I think we should say "AI agentapi url" rather than "llm agent url" for accuracy.

Also TODO: we need to update the claude code and goose terraform modules to use this.