fix(integration-events): dedupe Slack thread-parent across messages+threads trees

[khaliqgant]

Symptom

The operator saw the same Slack message echoing into the channel repeatedly. In integration-events.log, one message (1780946577_526789) appeared 59× — 25 received, 22 skipped (de-duped), but 3 injected (the visible echoes). The bot's own posts echoed too (compounded once the mounts went mirror and read the bot's own writebacks back down).

Root cause

A Slack thread parent (thread_ts == parent ts) materializes under two trees: the flat messages/<ts>/meta.json record AND the threads/<ts>/meta.json root — two distinct files, distinct revisions, but one logical message.

slackLogicalChangeFingerprint keyed them differently:

• messages/<ts>/meta.json → slack:channels:<ch>:message:<ts>:meta.json
• threads/<ts>/meta.json → slack:channels:<ch>:thread:<ts>:meta.json

Different fingerprints → different injection-dedupe keys → the same message injects once per tree, and re-injects as each tree's record is re-committed (revision churn). (event.type is the constant relayfile.changed and the separate messages/threads mounts yield the same dedupe path-tail, so the fingerprint was the only differentiator.)

Fix

Collapse the thread root (a threads/<ts> path with no replies/ segment) to the message identity in slackLogicalChangeFingerprint, so both materializations of the parent share one dedupe key and inject once. Thread replies keep their distinct :reply:<ts> identity and still inject.

One-line change in the fingerprint + a regression test.

Test

slack thread parent materialized under both messages and threads trees injects once — parent under both trees → 1 injection; a reply → still injects. 74/74 bridge tests pass (node --test src/main/__tests__/integration-event-bridge.test.ts).

Residual (follow-up, not in this PR)

An agent still receives one copy of its own outbound post, because mirror mounts read the bot's own messages back down and the bridge has no self-identity signal to suppress them. Fully killing self-echo needs the workspace's own bot-user id at the bridge — a separate change.

Source-only (bridge); activates on the next Pear rebuild+restart.

🤖 Generated with Claude Code

[codeant-ai]

Your free trial PR review limit of 300 PRs has been reached. Please upgrade your plan to continue using CodeAnt AI.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[agent-relay-code]

ℹ️ pr-reviewer: review only — no file changes were applied to the PR (nothing to commit after review). The notes below are advisory and were not pushed.

Reviewed PR #175 against the current checkout. I did not find a validated breakage requiring code changes.

Local validation run:
npm test -- src/main/__tests__/integration-event-bridge.test.ts passed.

Final PR state observed:
mergeable=true, mergeable_state=clean; check runs complete with checks success and packaged-mcp-smoke success. Cubic returned neutral due to review limit.

Addressed comments

• codeant-ai[bot]: raised only a quota-limit notice, no code finding to validate or fix.
• gemini-code-assist[bot]: raised only a daily quota-limit notice, no code finding to validate or fix.
• cubic · AI code reviewer: check output reported monthly review limit reached, no code finding to validate or fix.