### What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary:

Routine load creation published a mutable job to the scheduler before
serializing its create journal. The scheduler could change the job from
`NEED_SCHEDULE` to `RUNNING` before serialization, while runtime task
membership was not persisted. Replaying such a create record restored a
`RUNNING` job with no tasks. With stable source topology, the job could
remain stuck without consuming data.

This PR makes the create journal durable before publishing the job to
the scheduler. The scheduler cannot observe or mutate the job while its
initial `NEED_SCHEDULE` state is being serialized.

Before:

```text
publish job -> scheduler may change it to RUNNING -> serialize create journal
```

After:

```text
serialize create journal in NEED_SCHEDULE -> publish job -> scheduler creates tasks
```

The change does not modify `RoutineLoadJob.read()` or normalize states
during replay. There are no deployed historical Kinesis create records
that require compatibility recovery, and existing Kafka replay behavior
remains unchanged.

#### Separate cloud Kafka follow-up found during review

While evaluating a broader replay-time `RUNNING` to `NEED_SCHEDULE`
conversion, we found an independent ordering issue in cloud Kafka
automatic-partition recovery. `isKafkaPartitionsChanged()` can update
`currentKafkaPartitions` before `updateCloudProgress()` successfully
fetches the authoritative offset from Meta Service. If that fetch fails,
a later scheduler round can see stable topology and skip the Meta
Service retry. A recovery path that makes the job schedulable at that
point could create a task from stale FE metadata, repeat already
committed data, and regress stored routine-load progress.

This PR does not add that replay-time conversion and therefore does not
change or expose the cloud Kafka path. The cloud issue will be handled
separately by making authoritative Meta Service progress synchronization
a prerequisite for task creation and preserving the retry requirement
across scheduler rounds.

(cherry picked from commit 8310bc0)

### What problem does this PR solve?

Issue Number: None

Related PR: apache#68773

Problem Summary: The branch-4.1 FE test compiler targets Java 8, but
RoutineLoadJobPersistenceTest uses Map.of, which was introduced in Java 9.
Both COMPILE and FE UT fail at testCompile with cannot find symbol for
Map.of(int, long). Use Collections.singletonMap to preserve the same
partition offset fixture with a Java 8 compatible API. The persistence
ordering and scheduling assertions remain unchanged.

### Release note

None

### Check List (For Author)

- Test: Unit Test / Manual test
    - CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt ./run-fe-ut.sh --run org.apache.doris.load.routineload.RoutineLoadJobPersistenceTest: exit 0; 1 test, 0 failures, 0 errors
    - cd fe && mvn checkstyle:check -pl fe-core: exit 0; 0 violations
    - javac --release 8 API comparison: Map.of fails; Collections.singletonMap compiles
    - git diff --check: passed
- Behavior changed: No
- Does this need documentation: No