docs(flows): fix class-level persistence example to pass flow_id for state resumption

[Ghraven]

Fixes #5378

Problem

The class-level @persist() example in mastering-flow-state.mdx shows a second PersistentCounterFlow() that is expected to resume from the first run's persisted state. In practice both runs produce result 2 — the same output — because every PersistentCounterFlow() call generates a fresh UUID and thus writes to a new persistence slot rather than loading the previous one.

First run result: 2
Second run result: 2   ← should be 6, not 2

Root Cause

Flow.__init__ assigns state.id = uuid4() on every construction. The @persist() decorator saves and loads state keyed by this ID. When flow2 = PersistentCounterFlow() is called without arguments, it gets a different ID than flow1 and no prior state is found to restore.

Fix

Capture flow1.flow_id after the first kickoff and pass it to the second instance via inputs={"id": flow_id}. This routes flow2 to the correct persisted entry, so the second run resumes from value=2 and produces 6 (increment → 3, double → 6).

# First run
flow1 = PersistentCounterFlow()
result1 = flow1.kickoff()
print(f"First run result: {result1}")  # Output: 2

flow_id = flow1.flow_id

# Second run - pass the same flow_id to load persisted state
flow2 = PersistentCounterFlow(inputs={"id": flow_id})
result2 = flow2.kickoff()
print(f"Second run result: {result2}")  # Output: 6

Inline output comments are also added so expected values are explicit.