**Steps to reproduce:**
- Install the `l10n_pl_reports` module and switch to a `PL Company`.
- Create and confirm a vendor bill with a `Bill Reference` and `Taxes`.
- Navigate to Accounting > Reporting > Tax Report and select `This Month`.
- From the dropdown, click `JPK` > `Export XML`.
- Open the generated XML file and observe the `DowodZakupu` field.

**Observation:**
`DowodZakupu` contains the vendor `Bill Number` even 
when a `Bill Reference` is set.

**Root Cause:**
At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) 
instead of using the `Bill reference`(`ref`) when available.

**Fix:**
This commit ensures `DowodZakupu` contains the `Bill Reference`
when it is available in JPK exports.

**Reference:**
https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41)

[1]:
https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208

opw-6299827

Issue:
The MyInvois payload computed `cbc:PrepaidAmount` as `amount_total - amount_residual`, treating every reconciled payment as a prepayment. A payment made on or after the invoice date is an ordinary settlement, not a deposit, but the code recognized it as one anyway. The values reported for `PrepaidAmount` were wrong regardless of the invoice date, and for a fully paid invoice this also collapsed `PayableAmount` to 0.00, which LHDN rejects.

Root Cause:
LHDN only considers a reconciled payment a genuine deposit if it was received before the invoice date. The code applied no date condition at all, so any payment reconciled against the invoice was added to `PrepaidAmount` and reduced `PayableAmount` accordingly.

Fix:
Only sum reconciled payment partials whose date is strictly earlier than the invoice date as prepaid, so regular payments are no longer misclassified as deposits. As a safety net, if the valid prepaid sum still covers the full invoice amount (e.g. a full advance payment), reset it to 0 so `PayableAmount` always reflects the full amount_total instead of being reported as 0. Also omit the `PrepaidPayment` node entirely when there is no genuine prepayment, rather than emitting it with a 0.00 amount.

[Task-6404296](https://www.odoo.com/odoo/my-tasks/6404296)

Currently, when a search is made on the website, hybrid_list passes the
search term to autocomplete. Inside the autocomplete function, a search
is performed, then _search_render_results is called with all the results.
The data returned from _search_render_results is then sorted and returned
to hybrid_list where it's paginated.

This means, if the search results in 1000 records, we call
_search_render_results on all of them. This is an expensive function, and
much of it goes to waste if it's not the 50 products shown on the page.

This change sorts and paginates the records inside autocomplete before
running _search_render_results on the subset of 50 records that will
eventually be shown on the current page.

This optimizes the search by making the maximum recordset size
_search_render_results is run on to be 50, down from an unbounded number
scaling with products in the database.

The default cap for the number of search results is 500.

|  | 42 Results | 500 Results (Cap) | 1,000 Results | 35,000 results |
| --- | --- | --- | --- | --- |
| Queries Before | 195 | 1515 | 3191 | memory error |
| Queries After | 195 | 209 | 210 | 251 |
| Time Before | 3.62 | 4.50 | 5.92 | memory error |
| Time After | 3.75 | 2.78 | 1.98 | 2.67 |

Note: The differences in timing can be attributed to the initial query time for `_search_with_fuzzy`

opw-6381030