fix(buzz-db): return an empty page from get_channel_window when limit is 0

[hasky00]

Summary

get_channel_window in buzz-db can violate its own documented pagination
contract when called with limit == 0.

ChannelWindow::next_cursor is documented as Some iff has_more
(crates/buzz-db/src/thread.rs). The function derives has_more from a
limit + 1 probe row before truncation, but derives next_cursor from the
truncated row set:

q = q.bind(limit as i64 + 1); // limit == 0 → binds 1, fetches the probe row
let mut db_rows = q.fetch_all(pool).await?;
let has_more = db_rows.len() > limit as usize; // 1 > 0 → true
db_rows.truncate(limit as usize);              // → 0 rows
let next_cursor = if has_more {
    match db_rows.last() { Some(row) => …, None => None } // empty → None
} else { None };

With limit == 0 and at least one matching row, this returns
has_more = true and next_cursor = None, breaking the invariant. A
caller that trusts the contract (window.next_cursor.expect("has_more implies next_cursor") — exactly what the module's own pagination test does) panics,
and a keyset-pagination loop would spin forever returning empty pages.

The sole current production caller clamps the limit with .max(1), so this
isn't reachable from the HTTP surface today — but it's a latent contract
violation in a public Database API that any future caller can trip.

Fix

Guard limit == 0 at the top of get_channel_window and return an empty,
exhausted page (rows: [], has_more: false, next_cursor: None). This
honors the invariant and also skips a pointless database round-trip for a
zero-row request.

Test

Adds channel_window_zero_limit_reports_empty_exhausted_page, mirroring the
existing channel_window_* Postgres tests: it inserts rows, requests a
zero-limit window, and asserts the page is empty, has_more is false, and
next_cursor is None. (Marked #[ignore = "requires Postgres"] like its
siblings.)

Verification

• cargo fmt -p buzz-db -- --check — clean
• cargo check -p buzz-db --tests — clean
• cargo clippy -p buzz-db --tests — clean

The new test requires Postgres and follows the repo's existing
#[ignore = "requires Postgres"] convention.

---

🤖 Generated with Claude Code

[Chessing234]

Clear contract fix. The early limit == 0 return restores the documented next_cursor.is_some() iff has_more invariant that the limit + 1 probe otherwise breaks (probe row → has_more=true → truncate to empty → next_cursor=None). The ignored Postgres test is the right shape for this crate. One nit: consider whether any caller currently depends on the broken behavior as a "sentinel" — if not, this is merge-ready.

[Chessing234]

Approving the limit==0 pagination contract fix.

[hasky00]

i checked and no caller can currently depend on the limit 'limit ==0' behaviour as sentinel :
the only production path with external limit is the relay bridge ('crates/buzz-realy/src/api/bridge.rs') which clamps before calling into 'buzz-db' :

  let limit = filter
      .limit
      .map(|l| (l as u32).min(BRIDGE_WINDOW_MAX_LIMIT))
      .unwrap_or(BRIDGE_WINDOW_DEFAULT_LIMIT)
      .max(1);

So limit == 0 is floored to 1 and never reaches get_channel_window_with_session.

• The desktop command (desktop/src-tauri/src/commands/channel_window.rs) builds its filter with limit_rows.unwrap_or(50).min(200) and goes through the same bridge, so it hits that same .max(1) floor.

• All remaining call sites are tests in crates/buzz-db and buzz-test-client, all with limits ≥ 1.

So the fix only changes behavior for direct library consumers calling with limit == 0, where the previous result (has_more == true with next_cursor == None) violated the documented invariant rather than serving as any sanctioned sentinel. Should be safe to merge.

[hasky00]

it should me merged by now

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is eed74bde2f4797714335ac10c56c0b0244c1def4...ebad4bbea0fc5b29c87dc1cc85038b2f6d81f1e2.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review ebad4bbea0fc5b29c87dc1cc85038b2f6d81f1e2 to authorize a new review.
Any previous review applies only to its recorded range.

[hasky00]

Rebased onto current main and re-scoped the guard.

Since the last push, main split this function: get_channel_window is now a
thin pool wrapper over get_channel_window_on, and Db::get_channel_window_with_session
(the relay bridge's read path) calls get_channel_window_on directly on its
routed reader connection. A guard in the wrapper would have left that
production path still returning has_more = true with next_cursor = None
at limit 0, so the guard now sits in get_channel_window_on and the
regression test asserts both entry points.

@Chessing234 — flagging since this is a different diff than you approved.

Also: the Docker/CI checks here are red because the previous runs expired
unapproved after 30 days, not because anything failed. They need a maintainer
to approve the workflow runs.