Honour forget, reset and delete on the retrieve path, and read a resource text back

[bjmeetsfo]

Two follow-ups to the memory-API work merged in #133.

forget and reset were not honoured by /v1/retrieve

Both wrote a durable tombstone, and every read that goes through the Python serving pipeline
honoured it — get_all returned 0 immediately. /v1/retrieve does not go through that pipeline:
on a native backend the engine assembles the context pack itself, and it has never heard of a
memory tombstone (matrixark_memory_tombstone appears nowhere in the engine). So a forgotten
memory kept coming back from retrieve, verbatim, as type=event items:

before forget:  get_all=2, retrieve contains the subject's secret = True
forget:         http 200, removed_count 54
after forget:   get_all=0, retrieve contains the secret = STILL True

That is a deletion defect, not a ranking nuance, and it is invisible to any check that asks only
/v1/memories.

The engine could already do this and nothing called it. matrixark_forget_scope physically
removes a scope's records: it refuses an under-specified scope that would match everything,
rewrites each hash field down to its survivors, commits one durable batch, and clears the scan and
hgetall caches — its own comment says that last part exists "so a subsequent retrieve/get_all
never re-serves a forgotten record". The only mention of it anywhere in Python was an unrelated
test name. So this needed no engine change and no rebuild, just the wiring.

The tombstone is still written first, deliberately: it is the durable, auditable record of the
forget, it keeps the serving view correct even if the engine call fails, and its order-aware
semantics are what let a subject be re-ingested afterwards. If the engine call fails, the result
says so (engine_purge.ok = false) rather than reporting a clean forget over data that is still
there.

Scope handling is what the tests mostly cover, because getting it wrong is the dangerous part:

• forget recomputes the subject's identity hashes with identity_hashes. A request scope
  carries hashes derived from the caller, and purging with those removes the wrong subject. It
  keeps user_id, since dropping it would widen a forget into a tenant wipe.
• reset does the opposite: drops the user/session dimensions, keeps the tenant hash, and
  declines to purge at all when no tenant hash resolves — there is then no safe scope to hand the
  engine.

Verified live on the same store, before and after:

	before	after
forget	retrieve serves the secret	get_all=0 and retrieve clean
reset	retrieve serves the canary	get_all=0 and retrieve clean

delete, and a record-removal op in the engine

delete had the same hole, and could not be fixed by wiring: matrixark_forget_scope matches by
scope, and a delete addresses one memory. So this adds matrixark_delete_records.

It is deliberately a dumb primitive. Deciding what a delete covers is the subtle part — the
addressed event, its single-source derivatives, and the embeddings and index postings pointing at
any of them, while multi-source derivatives are demoted (rewritten with the source trimmed)
rather than removed. That rule already exists, once, in delete_memory. Re-deriving it in Rust
would put two copies of it in the tree in two languages, which is exactly the kind of drift these
fixes have been chasing. So the engine takes a list of ids and removes what matches; the caller
decides the list, and delete_memory now reports the set it decided instead of keeping it private.

The engine side mirrors forget_scope_records — same shard walk, same survivor rewrite, same
single durable batch that also clears the scan and hgetall caches. Only the predicate differs: a
record matches on any id it is addressable by, its own identity or a pointer it carries
(ref_hash, ref_hashes). Matching those pointers is what stops a delete leaving orphaned
postings behind that still surface the text.

An empty id list removes nothing and returns early. That guard is the whole safety story:
without it the walk would match every record and a no-op delete would wipe the store.

	before	after
delete	get_all 2→1, retrieve still serves it	get_all 2→1 and retrieve clean
reset	retrieve serves the canary	get_all=0 and retrieve clean
forget	retrieve serves the secret	get_all=0 and retrieve clean

All three deletion operations now mean the same thing on every read path.

Reading a resource's or skill's text back

list_skills and list_resources return a pointer (raw_uri, cloud_key) and metadata. The text
itself is already stored, split across resource_chunk records at ingest, but nothing reassembled
it — so "give me this skill's content" had no answer.

get_resource_content does, and pages it: an attachment can be far larger than belongs in one JSON
response, so it returns at most chunk_limit chunks and max_chars characters and reports
next_chunk_offset when there is more. skill_hash and resource_hash are aliases.

Ordering would have failed silently. Chunks carried no order of their own, so reassembly depended
on the log being read back in append order — a property of how it was read, not of the records.
Each chunk is now stamped with chunk_index at ingest and read back in that order, falling back to
log order for chunks written before the index existed, which is the only ordering those have. A
test builds the chunks out of order in the log and asserts the content comes back in the right one.

Verification

25 new tests. On this tree: mem0 suites 56/56, delete/forget 21/21, the native-path guard, the
record-cache suite, and both new suites green.