docs: propose writer-local ReadLatest support

[HaHaJeff]

Purpose

Linked issue: N/A

Propose a writer-local ReadLatest API for primary-key tables so an embedded application can read
the latest state accepted by its writer before snapshot commit, without changing normal snapshot
isolation for other readers.

The proposal defines visibility, read-view stability, primary-key merge behavior, resource lifetime,
compatibility, and an incremental implementation outline. It also records the validated prototype
surface and clearly marks the example API names as proposed rather than currently implemented.

Tests

• pre-commit run --files docs/proposals/writer-read-latest.md
• git diff --check origin/main...HEAD
• Verified the public branch is exactly one commit and changes only
  docs/proposals/writer-read-latest.md.

Documentation-only change; no code tests apply.

API and Format

No current public API, storage format, or protocol changes. The document proposes a future writer
API for community discussion.

Documentation

Adds docs/proposals/writer-read-latest.md with the motivation, scope, proposed API and semantics,
prototype validation, compatibility, and implementation outline.

Generative AI tooling

Generated-by: OpenAI Codex GPT-5

[CLAassistant]

All committers have signed the CLA.

[lxy-9602]

Thank you very much for this proposal. We have also recently been designing a similar capability in Paimon-cpp for several internal real-time use cases.
It would be great to schedule some time this week or next week to discuss the two designs. Our current direction focuses more on a unified solution for both primary-key and append tables, together with a pluggable interface that allows customized real-time indexing and reading implementations. We would be happy to share our current design and explore how these ideas could be aligned.

[HaHaJeff]

Thank you for the feedback. We would be happy to schedule a design discussion.

The core requirement behind this proposal is a stable, writer-local latest view: mutations should be readable before they are committed to a table snapshot, while the resulting read view remains valid as the writer continues its lifecycle. We see this as a low-level writer/read capability rather than a complete serving system.

Your unified design for primary-key and append tables sounds closely related. We would be interested in understanding how it handles pre-snapshot visibility and stable read views, and discussing how the two approaches could align.

Please let us know a convenient time and meeting channel.