memory_import_claude silently truncates section content at 4096 characters

### Summary

`memory_import_claude` stores at most 4096 characters per section. Longer sections are cut mid-word, with no warning, no `skipped`/`truncated` counter, and a `success: true` result. The lost tail is unrecoverable through semantic search, so a long memory silently becomes partially unsearchable.

### Environment

- ruflo CLI `v3.38.21`
- plugin `ruflo-core@0.2.6` (MCP tool `memory_import_claude`)
- Windows 11, Node v24.19.0
- native better-sqlite3 bridge enabled (`CLAUDE_FLOW_ENABLE_NATIVE_BRIDGE_ON_WINDOWS=1`)
- store: `C:\.swarm\agentdb-memory.db`

### Reproduction

1. Place a Claude Code auto-memory `.md` file longer than 4096 characters in `~/.claude/projects//memory/`.
2. Run `memory_import_claude` (I used `projectPath: "C:\"`, `namespace: "claude-memories"`).
3. Query the resulting row's content length.

### Result

The import reports full success:

```json
{ "success": true, "imported": 120, "skipped": 0, "duplicatesSkipped": 0, "files": 35 }
```

But content is capped. Across 119 imported rows:

```
rows at exactly 4096 chars : 14
rows > 4096 chars : 0
max content length : 4096
```

A distribution with 14 rows at *exactly* 4096 and none above is a hard cap, not a coincidence of content length.

Concrete case — source file is 9,960 characters, stored as 4,096, cut mid-token:

```
key : claude:C--:MEMORY:MEMORY
source : 9960 chars
stored : 4096 chars
stored tail : "...deflated exit sweep\r\n- [ml-"
```

The tail ends inside `- [ml-`, i.e. mid-word rather than at any section or sentence boundary.

### Expected

One of:

1. Store the full section content, or
2. chunk sections larger than the cap into multiple embedded rows (which would fit the existing chunk-per-heading model), or
3. at minimum, surface it — return a `truncated` count alongside `imported`/`skipped`, and log which keys were clipped.

Silent truncation is the core problem: the caller has no way to learn that recall coverage is incomplete.

### Impact

Semantic recall over long memories is silently partial. The affected rows still look healthy — present, `status='active'`, embedded — so the gap is invisible to any check short of comparing stored length against source length. In my corpus this affected 14 of 119 rows (~12%), including the index document that points at every other memory.

### Notes

Content is otherwise imported correctly: newlines are preserved (114/119 rows retain them) and every row is embedded (121/121, 384-dim all-MiniLM-L6-v2). The cap is the only defect I hit.

### Related

Separately from this, #3196 describes the `agentdb-memory.db` / `memory.db` split that determines *which* store an import lands in. This report is about the content cap within whichever store is written, and reproduces with the import landing in `agentdb-memory.db`.

Start at the memory_import_claude entry point and trace how section content is stored and how the 4096-character limit is applied. Reproduce the import with a section longer than 4096 characters, then add coverage showing that content is preserved, chunked, or explicitly reported as truncated. Done means long sections no longer disappear silently and the result communicates any affected keys or count.

Written by the indexing model from the issue text.