New replicated command carrying an optional kafka::offset. nullopt clears
the hint; Some(offset) sets it. Single command type covers advance,
lower, set, and clear. Apply path is a stub returning no-op; the real
implementation lands in a follow-up change.

Dispatch the new command in do_apply, store the value in state, and
signal the prefix-truncate loop so it can pick up the new target on
the next iteration.

Introduce prefix_truncate_target() that returns LRLO when the hint is
unset, or the log offset of the hint when set (clamped to LRLO).
max_removable_local_log_offset() continues to return LRLO so the storage
layer's reclaim path is unaffected.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>

Public entry point used by the reconciler to replicate the new command.
Idempotently no-ops when the cached value already matches.

Bytes-since-last-eval counter, last-eval timestamp, last-published value.
Used by the upcoming evaluate_local_retention path.

Compute the allowed_local_start_offset target from storage.mode,
cleanup.policy, and storage::log::retention_offset against effective
local-retention targets. Publish via ctp_stm_api when changed.
Idempotent when the value matches last-published.

The source class gains two virtuals (compute_local_retention_target,
publish_local_retention_target) so partition/ctp_stm-specific logic
lives in l0_source while the reconciler orchestrates decision and
bookkeeping. fake_source implements the virtuals as test hooks.

Bytes (>= segment_size_bytes), time (60s), and config-shape mismatch
triggers. Wired into per-source post-reconcile path and the idle tick.

Local footprint converges near retention.local.target.bytes;
flip to cloud and enabling compaction both evict aggressively.

In `tiered_cloud` mode the local log is prefix-truncated only up to
`min(LRO, allowed_local_start_offset)`, so it may still cover offsets
below LRO. Route those reads to the L0 (local) reader instead of L1
when the local log's start offset is at or below the requested start.

In `cloud` mode the local log is prefix-truncated to LRO, so the new
check is a no-op and the existing read-routing behavior is preserved.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>

Add storage::log::cloud_gc_offset() getter (implemented on disk_log_impl
and failure_injectable_log) so the ctp_stm's truncate loop can observe
the value the space manager publishes. The actual fix to
ctp_stm::prefix_truncate_target lands in a follow-up so this commit
demonstrates the bug:

* prefix_truncate_target_respects_cloud_gc_above_hint — set hint=20 and
  cloud_gc=60, expect target == cloud_gc. FAILS today (returns hint).
* prefix_truncate_target_clamps_cloud_gc_to_lrlo — cloud_gc above LRLO
  must clamp. Passes today by accident; locks the post-fix behavior.
* prefix_truncate_target_uses_hint_when_cloud_gc_below — cloud_gc below
  hint must not relax truncation. Passes today by accident; locks the
  post-fix behavior.

A small test-only accessor on disk_log_impl bypasses the
is_cloud_retention_active() gate in set_cloud_gc_offset so the cloud
topics fixture (with no ntp_config overrides) can drive the value
directly. Generalizing that gate so the space manager can drive
cloud_topics partitions in production is a separate concern.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>

In tiered_cloud mode the space manager publishes a cloud_gc offset per
log when disk pressure builds. disk_log_impl::do_gc consumes the value
for normal tiered storage, but cloud_topics partitions are exempt from
that housekeeping and rely on ctp_stm::prefix_truncate_below_lro
instead. Read cloud_gc through the new storage::log::cloud_gc_offset()
getter and raise the truncate target when it would drive more
aggressive eviction than the local-retention hint, capped at LRLO so we
never truncate unreconciled data.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>

…ions

The space manager (resource_mgmt/storage.cc) previously filtered out
cloud_topics partitions because they lack a remote_partition handle,
and disk_log_impl::{set_cloud_gc_offset,get_reclaimable_offsets}
explicitly rejected them via the is_cloud_retention_active() gate.
Combined with disk_log_impl::do_gc consuming any pending cloud_gc
unconditionally, the result was that the space manager could not
influence local retention on tiered_cloud partitions at all even
though their local log is exactly what disk pressure should reclaim.

Plumb the path end-to-end:

* Space manager: include partitions where cloud_topic_enabled() is
  true in the eviction schedule.
* disk_log_impl::set_cloud_gc_offset and get_reclaimable_offsets:
  accept cloud_topics partitions alongside tiered storage ones.
* disk_log_impl::do_gc: skip its cloud_gc consumption (and skip the
  reset) when the partition is cloud_topics so the value is left for
  the partition's own truncation loop.
* storage::log: add reset_cloud_gc_offset() so consumers can clear
  the value after acting on it (mirrors do_gc's clear-after-use
  pattern; ctp_stm needs it because it bypasses do_gc).
* ctp_stm::prefix_truncate_below_lro: after a successful
  snapshot_and_truncate_log, clear cloud_gc so the next space-mgmt
  round publishes a fresh decision rather than re-applying a stale
  one.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>

Adds test_space_manager_reclaim_under_pressure to the local-retention
suite. With tight retention_local_target_capacity_bytes and
retention_local_strict enabled, the space manager must shrink local
footprint below the reconciler-published hint, confirming that
max_removable_local_log_offset() is not gated by the hint.

Signed-off-by: Evgeny Lazin <4lazin@gmail.com>