Vendored the stream api and added the DeliverStreamRecords job.

[moedash]

This PR brings the native stream api into Core and adds the job that hands a workflow a consumed stream range.

What changed?

• The vendored api tree gets the rest of the stream api from Added the native stream protos. api#5: StreamSlice, StreamRange, StreamStartPosition, the subscribe and append commands and events, consumed_stream_ranges on the Workflow Task completed event and stream_slices on the poll response.
• The protos crate's type maps name the two new commands and events. Neither event is ignorable. The stream package gets its serde derives and its module.
• StreamRecord.body and .metadata aren't checked against the blob limit. Records never reach an event, and the server bounds a batch by message count instead.
• DeliverStreamRecords is a new activation job. The Rust SDK and the Rust workflow runtime have no stream API, so they fail the activation instead of ignoring it.

Part of AI-198 (epic AI-37).

Why?

Core can only decode the stream fields on a poll response or a completed event once its vendored api carries them. The job comes first so the machines and the delivery can build on it in the next two PRs. Failing in the Rust SDKs is on purpose: the server has recorded the range as consumed and won't send it again, so dropping it would lose data without a trace. There are no commands here yet, so nothing can subscribe through this PR alone.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

The workspace builds, cargo lint, cargo test-lint and cargo fmt --check are clean, and both commits build. The protos, common, client, SDK, workflow and Core unit tests pass. The vendored files are byte-identical to the api PR.