Apply solver_config.channels.filters when reading the channels table

Context

SolverConfig.channels is a TableConfig, so it already accepts a filters dict (solver_config.py:145, with TableConfig.filters at :61). The solver never reads it. When the channels table is loaded, only channels.column_name_mapping is applied (default_solver.py:1138); self.config.channels.filters is consumed nowhere in the engine. A user can set channel filters in config today and they are silently dropped.

By contrast, container_tags, container_metrics, and channel_mapping do apply their .filters at read time (default_solver.py:317, query_solver.py:79, default_solver.py:644) as equality predicates over filters.items().

Proposal

Apply channels.filters when the channels table is read, reusing the same equality-filter mechanism as the other tables. Filter keys reference internal column names (after column_name_mapping), consistent with the existing tables.

Scope

Channels table only for now. Do not wire up channel_tags, channel_metrics, or poi_channels filters in this issue. They are also currently accepted but ignored; track separately if wanted.

Acceptance criteria

• Reading the channels table applies each channels.filters entry as an equality filter, after column_name_mapping.
• No filters configured leaves current behavior unchanged.
• A test configures a channels filter that removes rows and asserts on real filtered values (not just row counts).
• configuration.md notes that channels-table filters are supported.

Start in default_solver.py:1138, then compare the existing equality-filter handling at default_solver.py:317, query_solver.py:79, and default_solver.py:644. Trace channels configuration from solver_config.py:145 and TableConfig.filters at :61, add a test with real filtered values, and update configuration.md. Done means channels.filters is applied after column_name_mapping while no-filter behavior remains unchanged.