[moetemp]

What changed?

This PR adds the Workflow write calls, the bodies of the append Local Activity and the close Activity of Workflow code. Workflow code still builds each request, and never calls the crate.

• WorkflowAppend writes as the Producer of a Workflow write, at attempt 1, so the attempts in one Workflow Task send the same batches. The runtime keeps the batches until the Store has them, so a retry in this process resends the same bytes after a random codec. Lang can then send no records.
• When the codec grew the merged Records past the Store's limits (4 MiB a batch, 1.5 MiB a Record), each publish goes in a batch of its own. A publish that the Store refuses alone as TOO_LARGE gets a StreamFailure, and the others get their last offsets. Any other refusal fails the call. A lasting one drops the kept batches.
• The first batch that the Store takes carries withdraw_run, so a first publish refused as TOO_LARGE doesn't skip the withdrawal.
• WorkflowAppendPending tells lang whether the runtime keeps the batches, so lang can skip the codec. The kept batches go past 64 MiB, oldest first.
• WorkflowClose closes as wf:<run id>, the run that scheduled the close, and only a Stream that the Activity's Workflow owns.

Depends on #222 (K12). Review lane is the Rust reviewers.
Part of the Brook review series.

Why?

sdk-python's _writes.py holds the resend cache, the split and the close Producer today. Each SDK needs the same rules, and only the codec call is tied to the language.

How did you test it?

cargo fmt, cargo clippy -- -D warnings (with and without features), cargo test -p temporalio-streams --all-features and cargo doc pass at this commit. The Workflow write suite runs on the memory Store here, and on Redis in R4 (temporal-community/sdk-streams#4).

[moetemp]

Parked. Nothing calls these runtime methods yet, since sdk-python does this work in Python. The branch stays, and this layer comes back with its first caller, for example a TypeScript or .NET port or Rust read handles.