**Description of the issue/feature this PR addresses:**

When downloading an attachment with an apostrophe in its name (e.g.,
file'name.zip), the system incorrectly downloads a text file containing
the URL instead of the actual file.

This occurs because of the current url validation check:
`if (anchor.href.indexOf(url) !== -1)`. When the raw URL is assigned to
the anchor's href attribute, the browser automatically normalizes
special characters (converting the literal ' to %27). The strict
string comparison then fails, causing the script to skip the XHR request
and fall back to generating a Blob from the raw URL string.

This commit resolves the issue by removing the overly strict indexOf
check. Based on the function's description, if it is called with
only one argument (no filename and no mimetype), the system already
expects that argument to be a URL.

By removing the check, we proceed directly to the XHR request. If the
payload is a valid URL (even with normalized characters), the download
succeeds. If raw contents are passed by mistake, the system will now
fail loudly with an XHR error that is easy to debug, rather than
silently downloading a text file named after its own contents.

**Steps to reproduce:**

- Discuss > choose any chat and upload any file containing an apostrophe > attempt to download the file > observe incorrect text file containing the URL string

**Current behavior before PR:**

- Downloading attachments with special characters such as apostrophes results in a text file containing the URL instead of the actual file

**Desired behavior after PR is merged:**

- Downloading attachments with special characters such as apostrophes results in the actual file

opw-6580287

Fixes #289575.

### Impacted versions

18.0 and 19.0. The constraint arrived with 081221a4cc2ff72f16be0e1d073112b938de0f19 ("[FIX] account_edi_ubl_cii, account_peppol: make PINT use UBL export", 2026-08-20).

master is not affected: the IBR constraint block was dropped from `account_edi_ubl_pint.py` there, so nothing checks the quantity.

### Steps to reproduce

1. A company with Peppol enabled, and a customer with a Peppol endpoint.
2. Create a customer invoice and set the **quantity to 0** on one line, leaving its unit price set.
3. Confirm, then **Print & Send** over Peppol.

### Current behavior

Sending is refused with `Line 1: Invoiced quantity is missing [IBR-022]`, although the quantity is there: `cbc:InvoicedQuantity` is built for every line and renders as `0.0`.

`account_edi_ubl_pint.py` read

```python
qty_node = line['cbc:InvoicedQuantity'] if is_invoice else line.get('cbc:CreditedQuantity', {})
if qty_node.get('_text') in [None, False]:
```

and `_text` holds the raw float taken from `base_line['quantity']` in `_ubl_add_line_invoiced_quantity_node`. Since `0.0 == False` in python, `0.0 in [None, False]` is `True`, so a present quantity of 0 is treated as missing.

`account.edi.xml.ubl_bis3` inherits `account.edi.ubl_pint_eu`, so this refuses plain Peppol BIS Billing 3.0 exports too, not only PINT.

### Expected behavior

The line exports and sends. A quantity of 0 is a value, and EN16931 BR-22 asks for the invoiced quantity to be present, not to be non-zero.

### About the fix

Absence is tested by identity, so 0 passes while a missing or `False` value is still reported:

| `_text` | before | after |
|---|---|---|
| `0.0` | reported missing | accepted |
| `0` | reported missing | accepted |
| `1.0` | accepted | accepted |
| `None` | reported missing | reported missing |
| `False` | reported missing | reported missing |

`isinstance(qty_text, (int, float))` would have been the shorter test but `isinstance(False, int)` is `True` in python, so `False` would no longer be caught.

The neighbouring constraints in that method do not share the problem. Nine of them read string values, where falsiness is the intended test, and the only other numeric one checks `isinstance(line['cbc:LineExtensionAmount']['_text'], FloatFmt)`, which no value of 0 can fail. `in [None, False]` occurs nowhere else under `addons/`.

### Test

`TestUblExportBis3BE.test_ubl_line_with_zero_quantity`, next to the existing `test_ubl_line_without_product_name`, which it follows. It asserts only on the quantity constraint, so the other constraints a minimal test invoice raises do not mask it.

Verified both ways on 18.0:

- without the fix: `AssertionError: ['Line 1: Invoiced quantity is missing [IBR-022].'] is not false`
- with the fix: `0 failed, 0 error(s) of 1 tests`

### Credit

Reported and diagnosed by @Robrechtc in #289575, including the cause and the suggested fix.