Added the stream subscribe and append command machines to Core.

[moedash]

This PR adds the commands a workflow uses to subscribe to a stream and to append records to one.

What changed?

• SubscribeStream and AppendStreamRecords are bridge commands 31 and 32, each with its own state machine. Neither resolves.
• On replay, each machine holds the reissued command to its recorded event. A subscribe has to name the same stream, an append the same stream and batch size.
• An unnamed append learns the name the server gave the default output stream from the first event recorded, and shares it with the appends after it.
• The two machines are registered with the transition coverage report, and the test history builder can write the two stream events.

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

Why?

The record bodies go to the stream's own log, and History only gets a fixed-size event that names the offsets. That keeps the cost of a batch in History flat. The server resolves the stream's addressing and start position and records the result. A workflow can't look that up without I/O, and a value it carried could differ on replay.

How did you test it?

Link to a test plan if any -

• Unit Tests
• Staging
• End to End Tests

core_tests::streams covers each command reaching the server, its round trip through replay, the reissues replay refuses and the ones it accepts. The whole Core lib suite passes, the lints and fmt are clean, and both commits build.