You are an expert database engineer and skilled programmer.

# Context
You will implement a specialized high-performance multi-threaded (${num_threads} threads) database engine in C++ that is optimized to only execute a predefined set of SQL queries.  The engine has two phases:

1. Load phase: Convert ArrowTable inputs into an efficient custom in-memory data structure, optimized for the specific queries being run. Datatypes and operators can be hard-coded to avoid interpretation overhead.
2. Execution phase: Execute the predefined queries against that data structure and write results to CSV files.

# System Overview
Queries: Defined in ${queries_path} (${query_str}).

Load phase is implemented in ${builder_path}, which predefines a Database struct. Your job is to populate it from ArrowTable inputs using an efficient in-memory representation. ${storage_hint}

Execution phase interface is predefined in ${query_impl_path}. It accepts a QueryRequest list and calls the corresponding query implementation for each request. 
Sample query implementations are provided in e.g., `query1.cpp/hpp`.
The output of each query should be written to `result<RUN_NR>.csv` (where `<RUN_NR>` is the 1-based position in the arg list), using: `delimiter=','`, `escapechar='\\'`, `quotechar='"'`, `header=True`.

${schema_hint}

# Your Task
Create a TODO plan for implementing this database engine. Write your plan to `${base_impl_todo_file}`. The plan should include concrete implementation steps in order, formatted so individual steps can later be marked as done. It should also include conceptual notes on data structure design and query execution strategy, covering both the build and execution phases.

Do not start executing any of your todo steps yet.

Do not use broad `find`, repo-wide `grep`, or directory scans when writing the plan. Limit inspection to `${queries_path}`, `${builder_path}`, `${query_impl_path}`, `${args_path}`, `${storage_plan_path}` (if referenced above), and the table schemas shown above. Do not read build scripts, framework internals, or system paths. If the storage plan is referenced above, read it now, during this planning stage - the plan you write here must be grounded in its actual content, not deferred to a later stage on the assumption it will be read then.

Note: the schema is reported in logical types; at runtime Arrow may expose a different physical type (e.g. DECIMAL128 instead of INT64, or DOUBLE instead of DECIMAL). You do NOT need to handle this yourself - the `column_ingest.hpp` helpers used in the build phase delegate to Arrow's safe cast. Plan the storage layout in terms of the logical column types and value ranges: use Arrow casts to decode correctly, then store the narrowest correct C++ representation in `Database`. Pick `scaled_integer<T>` for decimals/money/quantity, `as_integer<T>` for integer/code/key columns (T may be int8_t/uint8_t/.../int64_t/uint64_t), `as_string`, `as_date_days`, and `as_double`. Do not default to int64_t when the plan proves a narrower type is correct. If a needed flat scalar ingest case is missing, the implementation phase should extend `column_ingest.hpp` generically rather than adding ad hoc Arrow decoding to the loader.
