[prql-bot]

The Compiler interface section of the book's modules page describes a multi-file CLI that doesn't match prqlc. This PR rewrites that paragraph and example to describe what the compiler does. Following the old example either writes the output to a file named after the identifier, or fails with an IO error.

• Root-module rule. The page said the root is found by searching for .prql files starting with _. linearize_tree instead picks the file whose name starts with an uppercase letter. A _project.prql root fails with E0002 Cannot find the root module and the hint "add a file that starts with uppercase letter to the root directory". The repo's own fixture uses Project.prql.
• Example invocation. prqlc compile [INPUT] [OUTPUT] [MAIN_PATH] takes the main-pipeline identifier as the third positional argument. So prqlc compile _project.prql sales.projections.orders_2024 writes SQL to a file called sales.projections.orders_2024, and prqlc compile sales.projections.orders_2024 fails with No such file or directory. The new example is prqlc compile my_project/ - sales.projections.orders_2024, the same shape as the CLI test compile_project.

Checked locally with a my_project/ holding Project.prql and sales/projections.prql (let orders_2024 = (from orders | filter year == 2024)). The new command prints the filtered query, and renaming the root to _project.prql reproduces E0002. There's no regression test because the example is a plain console block that the book's snapshot tests don't run.

The rest of the page is a design spec (it opens with a warning saying so), and this PR leaves it alone.

[prql-bot]

The red build-prqlc and test-rust (wasm32…) jobs on this head come from main, not from this docs change. They stop with cannot update the lock file … because --locked was passed, and tests on main has failed the same way since the base commit 05f514a. #6483 re-resolves Cargo.lock to fix it, and once that lands, merging main here should turn these checks green.