The standard cron process reconciles batches of 100 bank statement lines at a time. In multi-company environments with large historical datasets, this query frequently timed out, exceeding the 15-minute execution limit. Even when throttled to a batch size of 10 records, the query required approximately 18.8 seconds to execute.

The performance degradation was driven by the following factors:

1. Suboptimal Lateral Filtering: The statement line batch array filter was placed inside the `LATERAL` block's `WHERE` clause. This prevented the query planner from optimizing the drive path effectively across iterations.
2. Inefficient Join Sequence and Filtering: The original join order scanned `account_move_line` before resolving the company hierarchy constraint. As a result, millions of rows across all companies were retrieved from the index, forcing repeated primary key lookups on `res_company` before ultimately discarding over 99.9% of the records via the late `parent_path` hierarchy filter.

This commit addresses these issues by:

1. Moving the `st_line.id` filtering constraint out of the lateral subquery and into the outer main query block to guide the execution path properly.
2. Reordering the inner `LATERAL` subquery to resolve the company hierarchy (`res_company`) prior to joining `account_move_line`. This constraints the scan boundaries early in the pipeline.

Performance Benchmarks (10 record batch):
- Before Execution Time: ~18,818 ms
- Before Shared Hit Blocks: 8,535,272
- After Execution Time: ~130 ms
- After Shared Hit Blocks: 67,204 ms

Before Plan: https://explain.dalibo.com/plan/h4739gh3519eaa43
After Plan: https://explain.dalibo.com/plan/5ebc5g8deff272gc