docs(rfc): define source and artifact REST APIs

[Zxf-xufeng]

Which issue or RFC does this PR close?

Proposes RFC #1437: Source and Artifact base REST APIs.

Scope creation, retrieval, and binding are defined separately by #1401. This RFC treats an existing scope_id as the parent resource and part of each resource's public identity.

Rationale for this change

PowerContext already provides domain-specific operations for Source capture, Memory flush, Experience and Skill evolution, and Handoff workflows. It does not yet provide a stable foundational HTTP API for accessing durable Sources and committed Artifacts without creating a second data or identity space.

This RFC defines a deliberately narrow API that reuses the existing Source journal, immutable Artifact revisions and heads, lineage, authorization, and family-specific domain models. Artifact Create also records its validated input as target-bound provenance without allowing that system Source to be consumed by another generation flow.

What changes are included in this PR?

• Add synchronized English and Chinese RFCs and keep them in the documentation navigation.
• Define seven Scope-qualified operations:
  • Source: Create and Get.
  • Artifact: Create, Get head, Get Revision, List, and Replace.
• Restrict the public Source type to content and Artifact families to memory, experience, skill, and handoff.
• Require family-specific domain validation and canonical serialization for Artifact Create and Replace.
• Flatten Artifact identity in responses and return ordered, read-only lineage through sources and artifacts arrays.
• Make Artifact Create atomically persist a target-bound lineage_only Content Source, Revision 1, head, and ordinal-zero Source lineage.
• Define shared Source-generation admission checks so Memory, Experience, Skill, Handoff, Candidate, and commit paths cannot reuse a lineage_only Source for another target.
• Require Source-window consumers to filter such Sources from model input while still advancing the complete journal cursor, including an all-filtered no-op case.
• Define opaque ETag semantics, If-Match optimistic concurrency for Replace, and If-None-Match conditional head reads.
• Map the public fields and internal Source role to the existing persistence model without requiring new metadata-table columns.
• Keep openapi/powercontext.yaml as the sole source of truth for the HTTP contract.

The RFC intentionally excludes Source List/Search, Artifact Search/Delete, cross-family List, client-writable lineage, Scope APIs, sharing, purge, and bulk mutation.

Are there any user-facing changes?

No runtime behavior changes are included. This PR documents the proposed public API, provenance rules, persistence mapping, compatibility boundaries, and implementation acceptance criteria.

How was this change tested?

• git diff --check
• uv run zensical build --clean -s (No issues found)
• Verified both generated RFC pages exist.
• Verified the published OpenAPI copy matches openapi/powercontext.yaml.

On macOS, the repository's make docs-test target stops at its GNU-specific install -D invocation. Running the equivalent file copy, strict Zensical build, output checks, and OpenAPI comparison succeeded.

AI usage statement

OpenAI Codex was used to compare the latest Yuque design with the repository RFC conventions, maintain English/Chinese parity, and draft the PR summary. The resulting RFC was reviewed and validated locally.

[Teingi]

LGTM