Hash described as 53-bit but is actually 32-bit

The comment claims a "53-bit FNV-1a-inspired hash", but Math.imul performs 32-bit integer multiplication with 32-bit truncation, and h >>> 0 produces a 32-bit unsigned result. The hash has only 2³² (~4.3 billion) possible values, not 2⁵³. Saying "fits in a JS safe integer" is true (32 < 53), but labelling it "53-bit" misrepresents the hash's entropy and could mislead future readers about collision resistance.

This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/messaging-dedupe.ts
Line: 35-42

Comment:
**Hash described as 53-bit but is actually 32-bit**

The comment claims a "53-bit FNV-1a-inspired hash", but `Math.imul` performs 32-bit integer multiplication with 32-bit truncation, and `h >>> 0` produces a 32-bit unsigned result. The hash has only 2³² (~4.3 billion) possible values, not 2⁵³. Saying "fits in a JS safe integer" is true (32 < 53), but labelling it "53-bit" misrepresents the hash's entropy and could mislead future readers about collision resistance.

```suggestion
  // 32-bit FNV-1a-inspired hash (Math.imul truncates to 32 bits; fits comfortably in a JS safe integer).
  let h = 0x811c9dc5;
  for (let i = 0; i < normalized.length; i++) {
    h ^= normalized.charCodeAt(i);
    h = Math.imul(h, 0x01000193);
  }
  // Combine prefix + length + full-text hash for uniqueness.
  return `${normalized.slice(0, 200)}|${normalized.length}|${(h >>> 0).toString(36)}`;
```

How can I resolve this? If you propose a fix, please make it concise.

Async recording creates a dedup window exactly when cross-turn dedup matters most

recordDeliveredText is called inside the second .then() — it only executes after onBlockReply (the Telegram send) resolves. For Telegram, onBlockReply is a network call and can take hundreds of milliseconds. If context compaction triggers and a new assistant turn begins during that window, isRecentlyDelivered returns false for the in-flight text (it has not been recorded yet), and the duplicate gets through — defeating the entire purpose of the cross-turn dedup.

The scenario this PR is fixing (#37702) is exactly this interleave:

1. Turn N emits text → Telegram send starts (async, in-flight)
2. Compaction fires → Turn N+1 starts with a fresh assistantMessageIndex
3. Turn N+1 re-emits the same text → isRecentlyDelivered sees an empty cache → delivers duplicate
4. Turn N's .then() finally fires and records — too late

Note the inconsistency within this PR: pushAssistantText (line 193) records synchronously before any delivery, so it does provide protection. Only the emitBlockChunk → emitBlockReplySafely path is affected.

A safer approach is to record the hash synchronously before calling emitBlockReplySafely (accepting the trade-off that a transient delivery failure would suppress the retry, which is less harmful than delivering a visible duplicate to the user):

// In emitBlockChunk, before calling emitBlockReplySafely:
recordDeliveredText(chunk, state.recentDeliveredTexts);
emitBlockReplySafely({ text: cleanedText, ... });   // no sourceText needed

And remove the async post-delivery recording from emitBlockReplySafely.

This is a comment left during a code review.
Path: src/agents/pi-embedded-subscribe.ts
Line: 114-125

Comment:
**Async recording creates a dedup window exactly when cross-turn dedup matters most**

`recordDeliveredText` is called inside the second `.then()` — it only executes after `onBlockReply` (the Telegram send) resolves. For Telegram, `onBlockReply` is a network call and can take hundreds of milliseconds. If context compaction triggers and a new assistant turn begins during that window, `isRecentlyDelivered` returns `false` for the in-flight text (it has not been recorded yet), and the duplicate gets through — defeating the entire purpose of the cross-turn dedup.

The scenario this PR is fixing (#37702) is exactly this interleave:
1. Turn N emits text → Telegram send starts (async, in-flight)
2. Compaction fires → Turn N+1 starts with a fresh `assistantMessageIndex`
3. Turn N+1 re-emits the same text → `isRecentlyDelivered` sees an empty cache → delivers duplicate
4. Turn N's `.then()` finally fires and records — too late

Note the inconsistency within this PR: `pushAssistantText` (line 193) records **synchronously** before any delivery, so it does provide protection. Only the `emitBlockChunk` → `emitBlockReplySafely` path is affected.

A safer approach is to record the hash **synchronously** before calling `emitBlockReplySafely` (accepting the trade-off that a transient delivery failure would suppress the retry, which is less harmful than delivering a visible duplicate to the user):

```ts
// In emitBlockChunk, before calling emitBlockReplySafely:
recordDeliveredText(chunk, state.recentDeliveredTexts);
emitBlockReplySafely({ text: cleanedText, ... });   // no sourceText needed
```

And remove the async post-delivery recording from `emitBlockReplySafely`.

How can I resolve this? If you propose a fix, please make it concise.

Avoid caching undelivered text during non-streaming retries

Recording recentDeliveredTexts inside pushAssistantText marks text as already delivered even when onBlockReply is not set and nothing has been sent to the channel yet; if auto_compaction_end later arrives with willRetry=true, resetForCompactionRetry() clears assistantTexts but keeps this cache, so replayed text in the retry attempt is filtered by shouldSkipAssistantText() and the final response can be truncated or empty. This regression is specific to non-block-reply flows that hit compaction retry.

Useful? React with 👍 / 👎.

Parse directive chunks before marking them delivered

emitBlockChunk now records every chunk in recentDeliveredTexts before it is parsed by replyDirectiveAccumulator.consume(...). When a chunk is directive-only (for example [[reply_to_current]]), nothing is emitted yet, but the hash is cached; if auto-compaction triggers willRetry=true, the retry can skip that directive chunk via cross-turn dedupe, so the accumulator never rebuilds pending reply metadata and subsequent text is emitted without the intended replyTo* target. This regression only needs a compaction retry plus split directive/text chunks to mis-thread replies.

Useful? React with 👍 / 👎.