imessage: typedstream length-prefix decoding truncates or empties messages ≥128 bytes

Filing here for a public record; also submitted through Claude Code's `/bug` channel, feedback ID `a25b9b79-6c61-4501-8ee9-d53a642a571a`, since `close-external-prs.yml` closes external code PRs by design and this plugin is in-tree.

**Bug.** `parseAttributedBody` (`external_plugins/imessage/server.ts:82`) reads a 1-byte length for the `0x81` typedstream escape, which specifies 2 bytes little-endian. Result: `true_length & 0xFF`. `0x82`/`0x83` are similarly one width too narrow.

**Impact.** Messages ≥128 bytes truncate mid-word with no marker. Messages whose byte length is a multiple of 256 decode to the empty string. On macOS 14+ `message.text` is NULL, so this is the primary read path. Measured on a live `chat.db`: 284 of the last 4000 messages decoded wrong, 1 decoded empty, largest recovery 3072 chars. Inbound channel messages share this path, so a truncated or emptied instruction reaches Claude as if it were complete.

**Fix + tests.** Branch: https://github.com/anthropics/claude-plugins-official/compare/main...illogicalproject:claude-plugins-official:fix/imessage-typedstream-length-prefix

Three-line arithmetic fix; decoder extracted to `typedstream.ts` because `server.ts` opens `chat.db` and starts the MCP server at module scope, so the function can't be asserted on in place. 11 tests; 7 fail against the current decoder, all 11 pass with the fix. Runs with `bun test`.

**Verification scope.** `0x81` is empirically verified — it covers 128 bytes to 64KB, where every real message lands, and is the only escape reachable in practice. `0x82` (payloads over 64KB) and `0x83` are corrected by inspection, not exercised by real data; a reviewer should treat them as unverified.

**The larger finding.** `external_plugins` has no test workflow and no plugin declares a `test` script — the nine workflows cover SHA bumps, URLs, frontmatter, licenses, manifests, and PR scope, and none run a test. That's why a modulo-256 error in a hand-rolled binary parser shipped 2026-03-18 and is still live, through anthropics/claude-code#41783 (closed as not planned). Happy to open a `bun test` workflow across `external_plugins/*` separately.

Environment: imessage 0.1.0 · Claude Code 2.1.247 · macOS 26.6.2 · bun 1.4.0

Start by reading external_plugins/imessage/server.ts around parseAttributedBody and the extracted typedstream.ts decoder, then run bun test. Done means the 11 typedstream tests pass, including 0x81 length cases, and long or boundary-sized messages decode without truncation or emptiness.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.