### Description

`from employees | eval x = 1 | keep x` results in 

```
Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.elasticsearch.xpack.esql.planner.Layout.getChannel(org.elasticsearch.xpack.ql.expression.NameId)" is null
        at org.elasticsearch.xpack.esql.planner.LocalExecutionPlanner.alignPageToAttributes(LocalExecutionPlanner.java:281)
        at org.elasticsearch.xpack.esql.planner.LocalExecutionPlanner.planExchangeSink(LocalExecutionPlanner.java:305)
        at org.elasticsearch.xpack.esql.planner.LocalExecutionPlanner.plan(LocalExecutionPlanner.java:199)
        at org.elasticsearch.xpack.esql.planner.LocalExecutionPlanner.plan(LocalExecutionPlanner.java:146)
        at org.elasticsearch.xpack.esql.plugin.ComputeService.runCompute(ComputeService.java:246)
        at org.elasticsearch.xpack.esql.plugin.ComputeService$DataNodeRequestHandler.lambda$messageReceived$5(ComputeService.java:415)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.action.ActionListener$2.onResponse(ActionListener.java:177)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.action.ActionListener.completeWith(ActionListener.java:305)
        at org.elasticsearch.xpack.esql.plugin.ComputeService.lambda$acquireSearchContexts$13(ComputeService.java:280)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.index.shard.IndexShard.ensureShardSearchActive(IndexShard.java:3911)
        at org.elasticsearch.xpack.esql.plugin.ComputeService.acquireSearchContexts(ComputeService.java:278)
        at org.elasticsearch.xpack.esql.plugin.ComputeService$DataNodeRequestHandler.messageReceived(ComputeService.java:413)
        at org.elasticsearch.xpack.esql.plugin.ComputeService$DataNodeRequestHandler.messageReceived(ComputeService.java:405)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:74)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.transport.TransportService$6.doRun(TransportService.java:1023)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:983)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:26)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.common.util.concurrent.TimedRunnable.doRun(TimedRunnable.java:33)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:983)
        at org.elasticsearch.server@8.10.0-SNAPSHOT/org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:26)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1623)
```
x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/CsvTests.java
* CsvTestsDataLoader creates an index using the mapping in mapping-default.json. The same mapping file is also used to create the
 * IndexResolver that helps validate the correctness of the query and the supported field data types.
 * The created index and this class uses the data from employees.csv file as data. This class is creating one Page with Blocks in it using
 * this file and the type of blocks matches the type of the schema specified on the first line of the csv file. These being said, the
 * mapping in mapping-default.csv and employees.csv should be more or less in sync. An exception to this rule:
 *
 * languages:integer,languages.long:long. The mapping has "long" as a sub-field of "languages". ES knows what to do with sub-field, but
 * employees.csv is specifically defining "languages.long" as "long" and also has duplicated columns for these two.
 *
 * ATM the first line from employees.csv file is not synchronized with the mapping itself.
 *
 * When we add support for more field types, CsvTests should change to support the new Block types. Same goes for employees.csv file
 * (the schema needs adjustment) and the mapping-default.json file (to add or change an existing field).
 * When we add more operators, optimization rules to the logical or physical plan optimizers, there may be the need to change the operators
 * in TestPhysicalOperationProviders or adjust TestPhysicalPlanOptimizer. For example, the TestPhysicalPlanOptimizer is skipping any
 * rules that push operations to ES itself (a Limit for example). The TestPhysicalOperationProviders is a bit more complicated than that:
 * it’s creating its own Source physical operator, aggregation operator (just a tiny bit of it) and field extract operator.
 *
 * To log the results logResults() should return "true".
 */
// @TestLogging(value = "org.elasticsearch.xpack.esql:TRACE,org.elasticsearch.compute:TRACE", reason = "debug")
public class CsvTests extends ESTestCase {
    private static final Logger LOGGER = LogManager.getLogger(CsvTests.class);
    private final String fileName;
    private final String groupName;
    private final String testName;
    private final Integer lineNumber;
    private final CsvSpecReader.CsvTestCase testCase;
    private final EsqlConfiguration configuration = new EsqlConfiguration(
        ZoneOffset.UTC,