[server] Prevent uncommitted ISR changes from being installed in CoordinatorContext

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.

### Motivation

When processing an `AdjustIsr` request, the Coordinator first attempts to persist all proposed leader and ISR changes through a batch ZooKeeper update. If the batch update fails, it retries each bucket individually.

Currently, a failed individual update is recorded as an error but then also receives an unconditional success result. In addition, all proposed changes are installed in `CoordinatorContext` and used for rebalance completion, regardless of whether their ZooKeeper writes succeeded.

This can cause:

- The same bucket to receive both error and success results.
- Failed ISR updates to be installed in Coordinator memory.
- `CoordinatorContext` to diverge from ZooKeeper.
- Rebalance completion to observe uncommitted ISR state.
- Future metadata propagation to publish non-authoritative ISR state.

### Solution

Explicitly separate proposed ISR changes from durably committed changes:

- Build and validate all proposed changes first.
- If the batch ZooKeeper update succeeds, treat all proposed changes as committed.
- If the batch update fails, retry each bucket individually and mark only successful writes as committed.
- Return exactly one success or error result for every requested bucket.
- Install only committed changes into `CoordinatorContext`.
- Run rebalance completion only for committed buckets.
- Keep validation failures out of ZooKeeper persistence attempts.

Add deterministic failure-injection tests covering batch success, fallback success, mixed individual outcomes, complete individual failure, and validation failures mixed with persistence outcomes.

### Anything else?

_No response_

### Willingness to contribute

- [ ] I'm willing to submit a PR!

Start at the AdjustIsr request handling path and trace how proposed changes are persisted through the batch and individual ZooKeeper updates, then how CoordinatorContext and rebalance completion consume them. Add deterministic failure-injection coverage for batch success, fallback outcomes, and validation failures; done means one result per bucket and only successfully persisted changes reach CoordinatorContext and rebalance completion.

Written by the indexing model from the issue text.