Slack Plugin 6.1.0: receive messages from a channel

[Klaas-Ritense]

Adds a receive-message action: a scheduled poller reads the channels a process link points at and starts a case per message, or continues a case with the reply in its thread.

• Channels are derived from the process links, so a configuration nobody links to costs nothing.
• A per-channel cursor keeps the first poll from turning a channel's history into cases; a claim table (slack_processed_message) makes two nodes polling the same channel safe.
• Thread replies are read per open conversation, from the position of the case that is furthest behind, because Slack keeps them out of a channel's history.
• post-message now records the thread it posted in, and can answer inside an existing one.

The sandbox app ships a stateful fake Slack (backend/app/imports/slack-mock) so the whole loop can be driven without a workspace, app or token.

Review fixes included

Two correctness bugs found reviewing the changeset, both covered by new tests in SlackClientTest:

1. Thread replies were reversed into newest-first. SlackClient.readConversation reversed every page on the premise that Slack answers newest first — true for conversations.history, but conversations.replies returns oldest first. The poller signals the waiting execution per message, so with two replies in one poll the case continued on the later reply and the earlier one — the answer it was waiting for — matched no waiting execution and was dropped with its claim already written.
2. filesUpload threw on a filename without an extension. fileName.split('.')[1] raised IndexOutOfBoundsException on LICENSE, and uploaded verslag.2026.pdf as a file of type 2026.

Known gap — documentation

documentation/plugin.md, documentation/getting-started.md and README.md do not yet carry their 6.1.0 sections; those changes were lost before this commit and need rewriting. documentation/release-notes.md is up to date. To follow up on this branch before merge.

Open design question

When maxPagesPerPoll is exhausted, the pages held are the newest stretch of the window and the cursor still advances to the newest handled message — so anything between the old cursor and the oldest page read is never fetched again. It is logged as a warning, but the outcome is a message that silently never becomes a case. Defaults make it rare (10 x 100 messages per 5-minute poll); worth deciding whether to keep the silent skip or stall the channel loudly instead.

Verification

• ./gradlew :backend:plugin:test --rerun-tasks — 59 tests, 7 classes, green, including SlackReceiveMessageIT against a real process engine.
• ng build @valtimo-plugins/slack — clean.