ops: show broker connection in baudbot status

[benvinegar]

Summary

• add broker connection reporting to baudbot status
• derive broker state from runtime bridge session and recent bridge telemetry
• update CLI help text and docs to mention broker connection status

Validation

• bash -n bin/baudbot
• attempted npm run test:shell locally, but vitest was not available in PATH in this environment

[greptile-apps]

Greptile Summary

Added broker connection status reporting to baudbot status command. The implementation checks broker configuration by validating all required SLACK_BROKER_* environment variables, then inspects the slack-bridge tmux session output to determine runtime state (connected, reconnecting, starting, disconnected, or not configured). Documentation updated in README.md and docs/operations.md to reflect the new status field.

Confidence Score: 4/5

• Safe to merge with minimal risk - well-contained operational enhancement
• The changes are well-scoped to status reporting only, matching existing patterns in the codebase. The shell script logic is defensive with proper error handling and fallbacks. One minor concern: the tmux pane capture approach relies on log message strings which could break if broker-bridge.mjs logging changes, but this is acceptable for an operational monitoring feature
• No files require special attention

Important Files Changed

Filename	Overview
README.md	Updated help comment to mention broker connection status reporting
docs/operations.md	Updated documentation comment to mention broker connection state in status output
bin/baudbot	Added broker configuration check and connection status reporting via tmux pane telemetry parsing

_{Last reviewed commit: b19343c}

[sentry]

Bug: The persistBrokerHealth function uses synchronous file I/O operations like fs.mkdirSync and fs.writeFileSync without try...catch blocks, which can crash the process.
_{Severity: CRITICAL}

Suggested Fix

Wrap the synchronous file system operations within the persistBrokerHealth function in a try...catch block. Log any errors that occur instead of allowing them to crash the process. This will make the health persistence mechanism more resilient to transient or persistent filesystem issues.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: slack-bridge/broker-bridge.mjs#L135-L142

Potential issue: The `persistBrokerHealth()` function performs synchronous file I/O
operations (`fs.mkdirSync`, `fs.writeFileSync`, `fs.renameSync`) without any error
handling. This function is called frequently from multiple critical paths, including at
startup and within error handling blocks of the main poll loop. A filesystem error, such
as a full disk or permission issue, will throw an unhandled exception, causing the
entire bridge process to crash and leading to a service outage.