### Commit 1:

We fetch and store bills if we're able to parse and store them correctly. but in case we make a mistake

1. The cron gets stuck trying to fetch the problematic bill.
2. Users have no clue that there is a bill on KSeF that they have to fetch manually.

---

1. Save the bill on a savepoint, to make sure one problematic bill doesn't affect others
2. Create all bills as draft first so that users have a reference to fallback to in case the have to do manual fetching.

---

task-6310321

---

### Commit 2:

Issues:

1. For a db with company_1 and company_2, when company_1 sends an invoice to company_2 via KSeF (out_invoice with a ksef number),
company_2 in the same database can't fetch the corresponding bill because there is a move with the same KSeF number.
2. The date difference between `from` and `to` in the `dateRange` must not exceed 3 months as explained in the documentation
https://api.ksef.mf.gov.pl/docs/v2/index.html#tag/Pobieranie-faktur/paths/~1invoices~1query~1metadata/post

Fixes:

1. Change the unique constraint and the domain to allow same KSeF number per different companies.
2. Minimize the `to` parameter with `from` + 2 months.
3. Increase the TIMEOUT to 30 seconds as 10 seconds is too small.

task-6260645

---

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272665
Forward-Port-Of: odoo/odoo#270511

### Issue:
When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice

Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist until the remaining quantities are invoiced, at which point the extra DDTs are moved to the new invoice

This creates inconsistencies in the generated XML, which references DDTs not actually covered by the invoice

### Cause:
The quantity allocation loop only checked whether there was remaining `move_qty` to consume, but never checked whether the invoiced quantity (`inv[0]`) had already been fully consumed

As a result, once all invoiced quantity was allocated, the loop kept iterating and linking additional DDTs from the sale order

### Steps to reproduce:
- Install `l10n_it_stock_ddt` with demo data
- Switch to the IT company
- Create a Warehouse
- Create a Product (Invoicing Policy: Delivered Quantities)
- Create and confirm a Sale Order (qty: 5) for that product
- Validate 3 partial deliveries of qty 1, creating a backorder each time
- Create the invoice, set the quantity to 2 and confirm

Before the fix, 3 DDTs were linked instead of 2

opw-6294035

Forward-Port-Of: odoo/odoo#270235

This commit adds a route for Digital Asset Links (`assetlinks.json`)
that link the domain with the Android Mobile App.

Also we adapt some functions authentication/registration so Odoo accept
request origin from the mobile App.
The origin should be `android:apk-key-hash:BASE64(SHA256(APP_SIGNATURE))`

Note: the `/.well-known/assetlinks.json` file should be serve on port
HTTPS (443) without that the Android Digital Asset Links will fail.

Url for debugging Digital Asset Links
https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https://MY-DOMAIN.local&relation=delegate_permission/common.get_login_creds&target.android_app.package_name=com.odoo.mobile&target.android_app.certificate.sha256_fingerprint=D6:73:20:02:CA:2D:01:C9:FD:FC:94:73:5A:D0:73:CF:2C:36:10:29:1F:4B:F7:5D:91:C2:1D:37:B2:18:E8:91

https://developers.google.com/digital-asset-links
https://developer.android.com/identity/passkeys/create-passkeys
https://developer.android.com/identity/credential-manager/prerequisites

opw-6279212

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#270551

Description of the issue/feature this PR addresses:

The actual XML extraction hardcoded the double-zipped case by reading only
   the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it
   was always a nested zip containing the XML.

This made it fail when:
- The XML was directly in the outer zip (single-zipped).
- The zip contained multiple files and the first nested zip didn't hold the XML.

Current behavior before PR:
After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file.
The XML File being double-unzipped, a traceback is raised.

Desired behavior after PR is merged:

The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback.

opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272121
Forward-Port-Of: odoo/odoo#268482