**Problem:**
Opening the invoicing dashboard causes an out-of-memory error on databases with many account.account records

**Cause:**
The standard invoicing dashboard uses:
  =ODOO.BALANCE(ODOO.ACCOUNT.GROUP("income"), $B$4)

`ODOO.ACCOUNT.GROUP` calls `get_account_group` server-side, which fetches all individual account codes for the given type (e.g. 2000+ on a French COA). These codes are sent to the client then forwarded back as `codes: [2000 strings]` to `spreadsheet_fetch_debit_credit`.

The server then builds a domain with 2000 individual LIKE conditions:
  account_id IN (SELECT id FROM account_account
    WHERE code LIKE '701000%' OR code LIKE '701001%' OR ... -- 2000 times)

This is repeated for each formula cell in the batch, causing the OOM.

**Solution:**
`get_account_group` now returns a lightweight type token per requested type (e.g. `["__type__income"]`) instead of fetching all individual codes. `_build_spreadsheet_formula_domain` detects the `__type__` prefix and converts it into a single efficient condition:
  account_id IN (SELECT id FROM account_account
    WHERE account_type IN ('income')
    AND company_ids IN (...))

The company filter previously implicit via `with_company().search()` is preserved explicitly using `_check_company_domain` in the subquery domain.

Manually entered code prefixes (e.g. `ODOO.BALANCE("40,41", year)`) are unaffected and continue to use the existing LIKE-based path.

Benchmark:
||Before|After|
|-|-|-|
||Memory error|-|

Related ticket:
opw-5964940

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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