slack bridge: attribute inbound human messages with the sender's name

[langwatch-agent]

Problem

When a person types in an agent's Slack channel, the bridge relays the text into the agent's tmux session with no author attached, so the agent cannot tell who is steering it. Agent-to-agent posts happen to self-label with a From <Agent>: line (a convention in each agent's prompt), and bot posts are dropped upstream, so only human messages hit this gap, and they are exactly the ones with no attribution. The Slack sender id was already on the event; it was just never surfaced.

This came up when an agent could not tell whether it was talking to one teammate or another, and defaulted to a stale identity from its environment.

Fix

• routeSlackMessage carries event.user on the deliver decision (kept pure; the id just passes through).
• SlackClient.resolveUserName resolves the id to a display name via users.info. users:read is already in the app manifest, so no scope change is needed.
• The bridge caches the name per user id and prefixes the relayed prompt with From <name> (Slack): before pasting. If the lookup fails, it falls back to the unprefixed text, so delivery is never blocked.

Only human messages reach this path (bot posts are ignored before it), so an agent's own From <Agent>: line is never double-labeled.

Tests

• New unit coverage: routeSlackMessage carries the sender id, and prefixAuthor labels a message / no-ops when no name resolves.
• Full non-e2e suite green (273/273). tsc --noEmit clean.
• The e2e-tmux real-tmux tests fail in this sandbox (2/4), but they fail identically on a pristine checkout of main with no changes, they drive the kanban send broadcast path this PR does not touch, and their own comment notes they need interactive tmux rendering. Unrelated to this change.

🤖 Generated with Claude Code

[drewdrewthis]

lgtm