chore: follow-ups for atomic change-tracking enablement (#20272)

[drmingdrmer]

Follow-ups from #20272 (none are merge blockers).

1. Docs: CREATE MATERIALIZED VIEW now auto-enables change tracking on the source

Before #20272 the statement failed when the source lacked tracking:

create materialized view mv as select ... from source;
-- SemanticError: Materialized view source table '...' must have CHANGE_TRACKING enabled

Now it succeeds and atomically sets change_tracking = true and begin_version on the source table, consistent with CREATE STREAM. User docs that instruct enabling CHANGE_TRACKING before creating an MV need updating. Worth stating in the same docs pass: dropping the MV (or a stream) does not disable tracking, so the source keeps paying per-mutation tracking overhead until it is disabled manually — pre-existing for streams, newly reachable via MV.

2. Duplicate source meta read in create_table on the MV path

When a CreateTableReq carries both source_table_option and materialized_view, create_table fetches the same source TableMeta twice per txn attempt:

// src/meta/api/src/api_impl/table_api.rs
if let Some(source_update) = &req.source_table_option {
    let source_meta = self.get_pb(&source_id).await?...          // read 1
}
...
if let Some(ref mv) = req.materialized_view {
    let source_table_meta = self.get_pb(&source_table_ident).await?...  // read 2, same table id
}

Reuse one read when source_update.table_id equals the MV source table id. Two extra KV round-trips per attempt inside the retry loop; minor, but free to remove.

3. Compat note: pre-#20272 binaries misreport stream_status for new-flow streams

A stream created by the new flow has stream.offset() < source.ident.seq with equal snapshot locations (enabling tracking advances the source meta seq without a new snapshot). Binaries that predate #20272 compare only seqs, so stream_status('s') and the admin endpoint report has_data = true for such a stream until the source's first data mutation or the stream is consumed. Stream reads still correctly return zero rows; a task triggered on stream status may fire one empty run. No code change needed — recorded for rollback / mixed-version operation awareness.

Non-goals

• No change to the privilege model (creating a stream/MV mutates the source table's options without ALTER on the source; pre-existing behavior for streams).
• No behavior change to stream_status on current binaries.