**Steps to reproduce:**
1. Install Accounting
2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments)
3. Test the imported records

**Issue:**
- `RecursionError: maximum recursion depth exceeded`.

**Cause:**
- In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`.
- While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`).
- By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop.

**Fix:**
1. Revert the assignment iteration back to `for line in self:`.
2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`.

By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion.

opw-6451854

Forward-Port-Of: odoo/odoo#282050

### Issue before this commit:
When creating a fixed-amount down payment on a sale order containing a fixed tax alongside percentage taxes, the invoiced down payment amount did not match the amount configured by the user.

### Steps to reproduce the issue:
1. Download Sales
2. Create a new tax with Tax Computation as Fixed, amount 8$ and a new tax group name
3. Create a sale order, set 1000$ as price, insert 15% tax and the new tax, confirm it
4. Click 'Create invoice' and create a downpayment with fixed amount of 500$
5. See that the amount of the downpayment are incorrect. In particular the untaxed amount is 431.78$ instead of 434.78$ and the tax amount is 68.22 instead of 65.22$

### Cause of the issue:
Fixed taxes are not proratable (their amount doesn't scale with price), so the down payment line generation explicitly excludes them when building each down payment line. However, the ratio used to prorate the down payment was computed as self.fixed_amount / order.amount_total, where order.amount_total still included the fixed tax amount. This mismatch meant the fixed tax contributed to the denominator of the ratio but was never represented in the resulting down payment amount, causing the invoiced total to fall short of the requested fixed_amount by a margin proportional to the fixed tax.
https://github.com/odoo/odoo/blob/baf2a1ee9d7df408aab8f3b5268a00d1161f9232/addons/sale/wizard/sale_make_invoice_advance.py#L233-L304

### Reason to introduce the fix:
The values inside the downpayement need to match with the ones inserted by the user and of the initial sale order.

opw-6410745

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

**Steps to reproduce:**
* Create a **French** parent company and a branch.
* Activate **Electronic Invoicing (PDP)** for the parent company.
* Switch to the branch while keeping both the **parent company** and the **branch** selected in the company switcher.
* Go to **Settings → French Localization → Activate Electronic Invoicing**.
* Activate **Electronic Invoicing (PDP)** for the branch.
* Select the **Participate in the pilot phase** checkbox and try to save settings.

**Observed behavior:**
* A traceback occurs with the error: `psycopg2.errors.SyntaxError: syntax error at or near ")"` on `IN ()` in the SQL query inside `_force_update_l10n_fr_f10_moves`.

**Cause:**
* `_force_update_l10n_fr_f10_moves` searches for receivable/payable accounts using `company_ids IN companies.ids`.
* A branch company has no accounts assigned directly to it — accounts belong to the parent company — so the search returns an empty list.
* Passing an empty tuple to `IN %(account_ids)s` generates `IN ()`, which is invalid PostgreSQL syntax.

**Fix:**
* Replace `('company_ids', 'in', companies.ids)` with
  `('company_ids', 'parent_of', companies.ids)` in the account search
  inside `_force_update_l10n_fr_f10_moves`.
* This ensures that accounts owned by a parent company are correctly
  found when the given companies are branches, since branch companies
  inherit their parent's chart of accounts.

opw-6394650