Add slack user level authentication

[ajinkyasraj]

Add a user-identity option to the Slack connector

Slack connections can now authenticate as the installing human (a xoxp- user token), in addition to the existing bot identity (xoxb-). This is additive — no bot functionality is removed; a connection simply picks one of two identities via auth_kind.

Why

A bot token only sees channels the app's bot user is invited to and cannot use Slack's search.messages API (Slack rejects bot tokens there). Some agent workflows need a human's full reach — every channel/DM the person can see, plus workspace search. A user-token connection provides that, scoped by a Sieve role + policy.

Identity model

Identity	auth_kind	Token	Reach	Acts as
Bot (unchanged)	oauth / token	xoxb-…	channels the bot is invited to; no search	the app's bot user
User (new)	user_token	xoxp-…	every channel/DM the user can see + search_messages	the installing human

Both identities expose the same curated operation set; they differ in reach and attribution. Bot remains the least-privilege default.

What changed

Connector (internal/connectors/slack)

• config.go: new KindUserToken constant + UserToken field; validate()/accessToken() branch on the kind (user kind requires an xoxp-/xoxe. prefix).
• ops.go: search_messages now runs for real on user-token connections (with page→cursor pagination); bot connections still return the typed connector.ErrOperationNotEnabled sentinel (→ HTTP 501 on REST, operation_not_enabled: tool error on MCP).
• slack.go: declares the user_token setup field so the registry architecture invariant stays satisfied.

Admin UI / web (internal/web)

• Two new routes: POST /connections/slack/oauth/user/start (OAuth install requesting user_scope, incl. search:read) and POST /connections/slack/user-token (paste a xoxp- User OAuth Token).
• slackOAuthExchange distinguishes a user install from a bot install by the presence of authed_user.access_token in the oauth.v2.access response — no side-channel flag.
• Reauth handles re-pasting a user token and re-running the matching OAuth identity (reads the stored auth_kind).
• connections.html: "Install via OAuth (as user)" button and "Add via user token" form on the Slack card, alongside the existing bot options.

Test mock (internal/testing/mockslack)

• Serves search.messages for user tokens (xoxp-/xoxe.) and keeps the not_allowed_token_type rejection for bot tokens.

Docs

• docs/connectors-slack.md, docs/connections-guide.md, and the CLAUDE.md Slack note updated for the bot-vs-user choice, the four install paths, and the revised search_messages behavior.

Testing

• go build ./... clean.
• go test ./internal/connectors/slack/ ./internal/web/ ./cmd/sieve/ all pass, including:
  • user-token validate/parse/accessToken cases and end-to-end search_messages (incl. pagination) against the mock;
  • user-token paste (happy + bad-prefix), user OAuth callback persisting auth_kind=user_token;
  • a regression test asserting the bot OAuth path still yields auth_kind=oauth;
  • the registry architecture invariant (user_token declared on Meta()).

Backward compatibility

Fully backward compatible. Existing bot connections (auth_kind oauth/token) are untouched; all existing Slack install/paste/reauth flows behave as before.