[BUG] Duplicate detection (IS_DUPLICATE) matches across different accounts instead of scoping to the account being imported

Bug Description

When importing activities via CSV, the duplicate detection (IS_DUPLICATE) appears to match transactions across different accounts belonging to the same user, instead of scoping the match to the specific account (accountId) referenced in the import file.

This means that if two separate accounts happen to hold the same symbol and, by coincidence, have a transaction with an identical date + unitPrice + quantity + type, importing the second account's activities will incorrectly flag those rows as duplicates of the first account's activities — even though they belong to entirely different accounts and represent genuinely distinct transactions.

To Reproduce

1. Create two accounts (e.g. "Fund X - Person A" and "Fund X - Person B") that both hold the same symbol/data source (e.g. a mutual fund on YAHOO).
2. Import a CSV of activities for "Fund X - Person A", including a row such as:
   复制

   Date,Code,DataSource,Currency,Price,Quantity,Action,Fee,Account
   2020-08-27,0P0001FEUD.F,YAHOO,EUR,11.2768,7.82846,buy,0,Fund X - Person A

3. Import a CSV of activities for "Fund X - Person B", containing a row with the same date, unitPrice, and quantity (same symbol/data source), but a different Account:
   复制

   Date,Code,DataSource,Currency,Price,Quantity,Action,Fee,Account
   2020-08-27,0P0001FEUD.F,YAHOO,EUR,11.2768,7.82846,buy,0,Fund X - Person B

4. The dry-run import for "Fund X - Person B" flags this row with:
   json复制

   "error": {
       "code": "IS_DUPLICATE"
   }

   even though it belongs to a different account than the one used in step 2.

Expected Behavior

Duplicate detection should be scoped per account (accountId), not globally per user/symbol/date/price/quantity. Two accounts legitimately holding the same instrument, purchased on the same date at the same price/quantity (e.g. two family members contributing to the same PPR fund on the same recurring date), should be treated as distinct transactions, not duplicates.

Additional Context

• Confirmed via the import dry-run API response, which returns "error": {"code": "IS_DUPLICATE"} on the affected activity object.
• Confirmed the transactions are genuinely distinct (different accounts, different underlying account holders) and not accidental re-imports.
• Workaround found: deleting/avoiding overlapping activities from one account before importing the other allows the import to succeed, but this isn't a real solution when both accounts legitimately share identical date/price/quantity combinations.
• Ghostfolio version: 3.61.0 (self-hosted, Home Assistant addon based on lildude/ha-addons).

Suggested Fix

Include accountId (or the account referenced in the import row) as part of the duplicate-matching criteria, in addition to symbol, data source, date, type, price, and quantity.