Per project style guide, function parameters and arguments should not
be split across multiple lines for better readability.

Thread safety note: The MetadataBatcher is already thread-safe with
proper mutex locking in both Add() and flush() methods. Multiple
concurrent metadata updates are correctly serialized.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

Changed MetadataBatcher implementation to match correct semantics:

- buf is now a slice with fixed capacity instead of a map
- Add() appends to slice, drops updates when buffer is full
- Flush triggers when buffer reaches capacity OR interval fires
- Removed 80% threshold logic - flush at exact capacity
- Multiple updates for same agent are now batched separately

This simplifies the logic and makes buffer overflow behavior explicit.
Updates are dropped with a warning when the buffer is full rather than
replacing existing entries.

Test updates:
- Renamed test to reflect new behavior (no replacement)
- Updated capacity flush test to fill buffer exactly
- Added new test for drop behavior when buffer is full

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

Implements Scenario 3 to drastically reduce pg_notify call volume.

Changes:
- Added WorkspaceAgentMetadataBatchPayload with array of updates
- Added WatchWorkspaceAgentMetadataBatchChannel() for global channel
- Batcher now publishes to both per-agent and batch channels
- Listener subscribes to both channels, filters batch for its agent

Performance impact:
- Reduces pubsub NOTIFYs from ~300/sec to ~0.2/sec (99.9% reduction!)
- NOTIFY rate now controlled by batch_flush_period config
- Rate = num_coderd_instances / batch_flush_period
- Independent of workspace/agent count

Migration strategy:
- Both channels published for backwards compatibility
- Per-agent channels can be removed once all clients migrate
- Listeners filter batched messages by agent ID

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

The batcher now only publishes to the global batch channel.
Per-agent channels are still used for the non-batched fallback path
(when batcher is nil in metadata.go).

During pod rollout all connections are dropped/reconnected, so there's
no need for backwards compatibility in the batcher path.

This achieves the target NOTIFY reduction:
- Before: ~300 NOTIFYs/sec (one per agent)
- After: ~0.2 NOTIFYs/sec (one per batch flush)
- 99.9% reduction in pg_notify call volume

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

Changed the batch notification to only send agent IDs instead of full
metadata details (keys, timestamps, etc). Listeners now re-fetch all
metadata for updated agents from the database.

Benefits:
- Smaller NOTIFY payloads (just UUIDs instead of keys/values/timestamps)
- Listeners automatically get complete, consistent metadata state
- Matches existing pattern from per-agent channel notifications

The listener already has this pattern:
- Receive notification with changed keys (or nil for all keys)
- Fetch those keys from database
- Update local cache

Now the batch notification sends: {"agent_ids": [uuid1, uuid2, ...]}
And listener fetches all keys for that agent.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>

Log which subscription channel (per-agent vs batch) receives notifications
to aid in debugging and monitoring the batching system. Includes agent_id,
keys for per-agent updates, and batch_size for batched updates.