fix(services/lakefs): follow the pagination cursor instead of stopping after one page

[PDGGK]

Which issue does this PR close?

None — found while reading the service.

Rationale for this change

The lister decodes LakefsListResponse, whose Pagination carries the cursor:

pub(super) struct Pagination {
    pub has_more: bool,
    pub max_per_page: u64,
    pub next_offset: String,
    pub results: u64,
}

and then sets ctx.done = true unconditionally. has_more and next_offset appear in the crate only in their own declarations (core.rs:319, :321) — nothing reads them.

So a listing returns the first server page and reports success. Nothing errors, nothing warns; the caller simply receives fewer entries than exist. lakefs does not declare list_with_limit, so no &amount is sent and the server's own default page size applies. And since it does not declare list_with_recursive either, a recursive listing is emulated by driving this lister per directory — so every level truncates independently.

What changes are included in this PR?

The cursor is fed back as after on later pages. The parameter already exists (core.rs:146), and the lister already sends the caller's start_after on the first page with the comment "start after should only be set for the first page" — this fills in the pages after it.

Why the encoding is in the same PR

core.rs:147 concatenated after raw:

url.push_str(&format!("&after={after}"));

next_offset is an object path chosen by the server. Driving the cursor is what makes a non-empty after reachable at all — before this change the parameter was only ever set from the caller's start_after. Shipping the cursor without the encoding would therefore introduce exactly the defect #8073 fixed across five services: a key with a space aborts the request with invalid uri character, one with # truncates the parameter and silently rewinds the page, one with & grafts a stray parameter. Splitting them would mean knowingly landing a regression and fixing it afterwards.

percent_encode_path is the right helper here — next_offset is a path, and it is what prefix on line 135 already uses.

Tests

None. The behaviour is the server's pagination contract, and there is no directory under .github/services for lakefs, so nothing exercises the lister either way.

What I can and cannot claim, stated plainly: that the fields are parsed and never read is verified by grep over the crate; that after is the parameter to feed next_offset back into rests on the two names and on after already being this endpoint's resume parameter. I have no lakeFS instance to confirm it against. If you would rather see it exercised first, say so and I will leave it.

cargo build, cargo clippy -p opendal-service-lakefs --all-targets (zero warnings) and cargo fmt --all -- --check are clean.

Are there any user-facing changes?

Yes: listing a directory with more entries than one server page returns all of them instead of silently stopping at the first page.