KAFKA-20770: LocalLeaderEndPoint should return UNDEFINED_EPOCH when the leader epoch cannot be resolved

[SEPURI-SAI-KRISHNA]

LocalLeaderEndPoint (used by ReplicaAlterLogDirsThread) and
RemoteLeaderEndPoint (used by ReplicaFetcherThread) implement the same
LeaderEndPoint contract but disagree on the leader epoch reported when
the epoch for an offset cannot be resolved from the leader epoch cache.
The remote path goes through ListOffsets, where the epoch is left unset
and serializes as -1 (NO_LEADER_EPOCH); LocalLeaderEndPoint instead
fabricated epoch 0 via epoch.orElse(0) in fetchEarliestOffset,
fetchLatestOffset, fetchEarliestLocalOffset and
fetchEarliestPendingUploadOffset.

This matters because the returned epoch is consumed by
TierStateMachine#buildRemoteLogAuxState, which treats it as meaningful:
epoch 0 short-circuits the earlier-epoch lookup, while other values drive
an OffsetsForLeaderEpoch probe and an epoch-based remote log segment
metadata lookup. A fabricated 0 claims the first leader epoch rather than
admitting the epoch is unknown, so the two fetcher paths behaved
differently for identical log state. The fallback is only reachable when
the epoch cache is empty or truncated above the queried offset (for
example after checkpoint loss), so this is a correctness/consistency fix
rather than a data-loss fix.

Replace the fallback with UNDEFINED_EPOCH (-1), matching the
ListOffsets-based path. Behavior is unchanged whenever the epoch is
resolvable.

Testing: the existing LocalLeaderEndPointTest assertions computed the
expected epoch with the same epochForOffset(...).orElse(0) expression as
the production code, so they could not catch this; they now assert
concrete values. Added tests covering a non-zero resolved epoch across
leader epochs and the unresolvable-epoch case for all four methods; the
new tests fail without the fix (epoch 0 returned) and pass with it.
LocalLeaderEndPointTest and ReplicaAlterLogDirsThreadTest pass locally.

Co-Authored-By: Claude Fable 5