Slack bot: drop the useless DM greeting, add real OAuth authorization completion

Two independent cleanups, filed together since both surfaced from the same live-usage session.

1. Remove the greeting - it's dead weight

agentSessions.ts's app_home_opened handler (GREETING, greetedDm Set) only ever exists to post "Tag me with a prompt and I'll run it against mecatl." the first time a user opens the bot's Messages tab. Confirmed via DESIGN.md: this is entirely separate from the actual DM prompt-handling path (app.message(...) filtered on channel_type === "im") - deleting it changes nothing about the bot actually working.

It's also buggy and slightly wrong:

• greetedDm is in-memory only, wiped on every restart - a returning user can see the greeting repeat itself, and with several allowlisted users' Slack clients syncing around the same time after a restart, that can look like an unprompted mass-DM even though it's per-user and reactive, not a broadcast.
• The text itself describes the channel @mention flow ("tag me"), which doesn't apply to DMs at all - in a DM you just type a message, no tagging.

Given the bot's current population is a small, already-briefed allowlist (not the general public discovering it cold), the onboarding value is near zero. Delete rather than fix:

• Remove the app_home_opened handler, greetedDm, and the GREETING constant from agentSessions.ts.
• Drop app_home_opened from slack-app-manifest.json's event subscriptions.

2. Let a user actually complete a mid-run OAuth authorization

#1283/#1287 fixed the failure mode (a stuck "live external authorization" precondition no longer wedges the thread's session forever) but deliberately left the feature out of scope: nothing in this bot can complete an interactive OAuth consent a tool call needs (e.g. a first-use connector-gateway tool, per flux/staging2/mecak8s/helmrelease.yaml's mcp.broker/DCR config in stacklok/infra). Right now a user hits this and gets told (post-#1287) "ask your administrator" - even though completing it themselves might be exactly what should happen.

This needs the actual mechanism, not just a graceful failure:

• Detect when a run needs an external authorization and the server surfaces a URL for it (check whether the error/event actually carries one - not confirmed either way yet).
• Post that URL to the user in Slack (ephemeral, matching #1242's scoping - this is exactly the kind of message that must not broadcast to a whole channel).
• Handle the callback/resumption so the run actually continues once the user completes it in their browser, instead of requiring a fresh session on the next message.

This is real, unscoped feature work - closer to a design pass than a quick fix. Worth its own investigation into what the server-side broker actually exposes to a client before committing to an implementation shape.