refactor(core): make accepted note snapshot persistence indivisible

[phernandez]

Summary

Make the DB-first accepted-note transaction expose one operation that persists the complete accepted Markdown snapshot: entity fields, NoteContent, observations, outgoing relations, and hot search state.

Why

PR #1079 fixed a real production regression where accepted writes returned success while graph rows remained empty. The immediate bug is fixed, but the API still permits the same incomplete state:

1. callers invoke persist_accepted_note_write() for NoteContent and search;
2. create/update/edit callers must separately remember replace_accepted_note_graph().

That invariant belongs in one operation. A future mutation path can currently omit the second call and recreate #1076.

This was identified while applying the /pythonic-code review lens from #1095 to the shared runtime introduced by #1002.

Proposed Direction

• Introduce one clearly named accepted-snapshot persistence operation for create/update/edit.
• Accept the prepared Markdown value and persist all derived rows through the caller-owned AsyncSession.
• Keep move as an explicitly narrower operation when it does not replace the note graph.
• Make partial content/search-only persistence private or otherwise impossible to invoke accidentally from a mutation runner.
• Preserve the existing local/cloud transaction and materialization behavior.

Prefer one direct function over a new service hierarchy.

Regression Proof

Add a route-level SQLite test that:

1. uses production-style deferred materialization with the worker held or not drained;
2. creates or edits a typed note;
3. asserts entity, NoteContent, observations, relations, and search state immediately after the accepted response;
4. only then permits materialization/indexing to run.

This ensures a later index_file pass cannot conceal an incomplete accepted transaction.

Acceptance Criteria

• Every accepted create/update/edit transaction persists the complete snapshot through one production call.
• There is no callable production path that writes NoteContent and search while accidentally omitting the graph.
• The pre-materialization regression test passes for create and at least one replacing mutation.
• Existing materialization, conflict detection, status codes, and queue behavior remain unchanged.
• Any Basic Memory Cloud adaptation is identified and validated against the paired revision.

References

• refactor(core): add shared runtime orchestration #1002
• DB-first note writes omit observations and relations until a later file re-index #1076
• fix(core): persist observations and relations on DB-first accepted writes #1079
• feat(skills): add Pythonic code guidance #1095

[claude]

Claude finished @phernandez's task in 2m 9s —— View job

---

Triage complete

• Read issue and gather context
• Classify type, priority, component, complexity
• Check for duplicate issues
• Apply labels
• Post triage summary

Classification

• Type: Enhancement / refactor (already labeled enhancement) — this is not a live bug report. The underlying data-loss bug (empty observation/relation rows after a DB-first accepted write) was already fixed in fix(core): persist observations and relations on DB-first accepted writes #1079; this issue asks to make that fix structurally unbreakable.
• Component: Core persistence layer — src/basic_memory/indexing/accepted_note_write_runner.py (persist_accepted_note_write, replace_accepted_note_graph) and src/basic_memory/indexing/accepted_note_mutation_runner.py (_run_accepted_note_create, _run_accepted_note_update, _run_accepted_note_edit), plus a cloud-side check per the acceptance criteria. Already labeled cloud.
• Priority: Medium. There's no active production incident — all three mutation call sites currently do call both persist_accepted_note_write() and replace_accepted_note_graph() correctly (verified by reading the current code). The risk is regression-by-omission in a future mutation path, which is exactly the failure class DB-first note writes omit observations and relations until a later file re-index #1076 already demonstrated once.
• Complexity: Medium. The change is scoped to one new/renamed function that composes existing pieces (create/accept_note_content_write, refresh_accepted_note_search_index, replace_accepted_note_graph) behind one call per mutation, keeping move as the deliberately narrower path. The harder part is the regression test: a route-level SQLite test that holds materialization back and asserts entity/NoteContent/observations/relations/search all landed from the accepted response alone, before any index_file pass runs — plus validating the Basic Memory Cloud call sites against the same invariant.

Duplicate check: No duplicate found. Reviewed #1002 (merged — added the shared runtime orchestration this issue targets), #1076 (closed — the original data-loss bug), #1079 (merged — the fix that added the separate replace_accepted_note_graph() call), and #1095 (open — the /pythonic-code review skill that surfaced this gap). This issue is a legitimate, non-duplicate follow-up authored by the same person who did the prior work.

Labels: This issue already carries enhancement, cloud, and python, which fit. I attempted to add priority/component/complexity labels (medium, database, testing, and variants) per the triage label taxonomy, but the repository's label set doesn't currently contain those names — the label-add script reported them all as unknown, and checking labels on related issues (e.g. #1076 only has bug) confirms this finer-grained taxonomy isn't provisioned yet in this repo. No changes were made beyond the labels already present.

Per triage scope, no implementation, branch, or code changes were made — this is scoping/labeling only.