### 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

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

Forward-Port-Of: odoo/enterprise#120855

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