docs(rfc): propose shared artifact merge and undo

[frf12]

Which issue or RFC does this PR close?

RFC #1859 proposal. Extends RFC #1809 and builds on implementation PR #1857. Related registration direction: RFC #1549. No issue is closed by this documentation PR.

Dependencies and merge order: wait for #1809 and #1857 before merging this RFC. Keep #1857 and implementation #1880 in the same release batch so its private Atomic Memory state-table format is not released.

Rationale for this change

Artifact Families need reusable merge and undo operations backed by common database tables, so adding a Family does not require separate merge-state, relationship, or undo tables.

What changes are included in this PR?

• English and Chinese RFCs following the repository example's metadata and nine sections.
• A common Artifact write boundary for creation, revision, and merge-state checks; business logic explicitly decides whether and when to merge.
• Shared merge records, frozen inputs, exact history, cascading undo, and preview consistency. Restore and undo append revisions for affected Artifacts, preserve historical revisions and original merge relationships, and make the whole operation’s committed result inspectable from the primary new revision. Atomic Memory uses the common operations and tables from its initial delivery.
• Scope, tradeoffs, and acceptance expectations; concrete schemas and operation parameters remain for implementation design.

Are there any user-facing changes?

Documentation only. This PR changes exactly the two RFC files and does not change runtime behavior or the HTTP contract.

How was this change tested?

• The initial RFC passed all 11 full-repository hooks. For the appended-restoration update, the applicable document checks, ty check, and commit hooks passed; file-type-specific hooks with no applicable files were skipped.
• Repository commit hooks on the staged RFC files.
• Compared metadata and all nine top-level sections against both 0000_example.md files; checked UTF-8, relative links, and English/Chinese consistency.
• git diff --cached --check; verified that the branch contains only the two RFC files.

No application tests or full website build were run for this documentation-only change.

AI usage statement

Prepared with OpenAI Codex, including source inspection, bilingual drafting, and independent review under maintainer direction.

[AlexStocks]

💭 Nit: common write layer is load-bearing but never defined

grep -rln "common write layer\|公共写入层" docs/{en,zh}/rfcs/ matches this RFC only — no other RFC in the library uses the term, and neither does the rest of docs/. The English and Chinese versions are consistent with each other (3 occurrences each, at :9, :74, :84 ↔ :9, :66, :73).

Worth a definition because line 74 makes it a binding constraint rather than a description:

Families can retain their business entry points but cannot bypass the common write layer to modify [...]

A reader who does not already know which code that is cannot check that constraint, and the sentence reads as if it names something established. The implementation it corresponds to is builtin/persistence/artifacts.py:71 ArtifactRepository plus the builtin/records.py changes — both of which are named elsewhere in the proposal but never tied to this phrase.

Either way works, and neither blocks anything:

• define it once at first use (:9), e.g. "the common write layer (builtin/persistence/artifacts.py ArtifactRepository and the record helpers behind it)", or
• drop the coinage and reuse ArtifactRepository, which 5 other RFCs already use by name.

Not a correctness issue — the intent is clear from context, and the rest of the proposal holds up. The six references this RFC makes to already-merged material (RFC 1809's merge/undo semantics via the PR link, the dedicated pc_atomic_memory_states table with its four-value state check constraint, restoration.py's first-revision-plus-lineage input resolution, and RFC 1549's "no branches keyed on Family name" principle) all check out against the actual sources.

One thing that will need attention later, not now: #1809 and #1857 are both still open, and :15-16, :124 depend on them. The file-path-vs-PR-link convention is correct today; it just needs revisiting when those land.

[frf12]

Defined common write layer at first use in both the English and Chinese RFCs in a49e7b2 as ArtifactRepository and its shared persistence implementation. Families retain their business entry points and decide whether to merge; this clarification does not introduce another abstraction.

This PR must not be merged until both #1809 and #1857 have been merged. The merge order is #1809 and #1857 first, then #1859; the references should be checked against their merged versions before #1859 is merged.