[opt](lance) push down LIMIT into Lance fragment scanners

[Jay-ju]

What problem does this PR solve?

Issue Number: N/A

Related PR: #65730, #66581

Problem Summary:

Ordinary Lance scans currently read every row of a fragment even when the
query only needs the first N rows (e.g. SELECT ... LIMIT 10). Lance applies
its own LIMIT after the scanner's filter, so the query LIMIT can be forwarded
to each fragment scanner and let it stop early, cutting IO and decode cost.

How it is fixed

• thrift: add an optional TLanceFileDesc.limit.
• FE (LanceScanNode): push the query limit into each fragment split via
  canPushDownLimit(), and surface lanceLimit in the explain output.
• BE (lance_reader): forward it to the scanner through
  lance_scanner_set_limit for ordinary scans; vector search keeps its own
  top_k limit.

Correctness

The limit is pushed only when all predicates are already pushed into Lance
(no residual Doris conjunct). Otherwise Doris still re-filters the returned rows,
and truncating a fragment early could drop valid results.

OFFSET needs no special handling: Nereids' SplitLimit rewrites
Limit(limit, offset) into a global Limit(limit, offset) over a local
Limit(limit + offset, 0), and that local bound is what reaches the scan node.
So getLimit() already includes the offset; each fragment fetches up to
limit + offset rows and the upper global LIMIT still applies the offset and
the final bound. Per-fragment truncation is therefore always safe.

Behavior change

Query results are unchanged. Only the number of rows scanned per fragment is
reduced for LIMIT queries; the explain output shows an extra lanceLimit=N
line when the limit is pushed.

Release note

Push down LIMIT into Lance fragment scanners to reduce the rows scanned for
LIMIT / LIMIT ... OFFSET queries over Lance tables.

Check List (For Author)

• Test
  • Unit Test (LanceThriftContractTest covers the limit round-trip and the no-limit case)
  • Manual test — SELECT * FROM <lance_tbl> LIMIT 10 returns 10 rows and EXPLAIN shows lanceLimit=10; a query with a non-pushable predicate keeps the limit out of the scan
• Behavior changed:
  • No.
• Does this need documentation?
  • No.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[Jay-ju]

Thank you for your contribution to Apache Doris. Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

Thanks for the reminder! I've just updated the PR description with the
problem background, the fix, the correctness reasoning (including how
OFFSET is handled) and the test plan. Please let me know if anything is
still unclear — happy to add more detail. 🙏

[Jay-ju]

@hello-stephen Please take a look when you have time, thanks.