Document the per-architecture source directory convention

Sources that ship one archive per architecture live in their own
sources/<name>/ directory and are mounted as a whole, so adding other
sources never invalidates their build layer.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

AGENTS.md

@@ -10,6 +10,7 @@
 - Append new dependency build steps after all existing dependency build steps. Do not insert or reorder steps in the existing build sequence, so previously successful build layers remain unchanged.
 - The DuckDB `ui` extension (`duckdb-ui`) is built in the same step as DuckDB instead of a separate step. It is statically linked into the DuckDB shell and can only be compiled as part of the DuckDB source tree (via `-DDUCKDB_EXTENSION_CONFIGS`), against the matching DuckDB version. Keep its pinned commit in the same `RUN` as DuckDB and update the two together. Because DuckDB is built from a tarball, pass `-DOVERRIDE_GIT_DESCRIBE` with the DuckDB version so the extension selects the correct API.
 - The log4cplus build also takes its required `ThreadPool` dependency in the same step, as a second source archive extracted into `src/threadpool`. log4cplus `REL_2_0_5` pins `ThreadPool` to commit `cc0b6371d3963f7028c2da5fc007733f9f3bf205`; keep the two in sync and do not fetch unused log4cplus submodules.
+- Sources that ship one archive per architecture (such as Rust) go in their own `sources/<name>/` directory, keeping the architecture in the file name. `fetch-sources.sh` downloads the archive for `uname -m`, and the Dockerfile mounts the whole directory (`source=<name>`) and selects the file with `$(uname -m)` in the same `RUN`. Do not create architecture-neutral hard links or symlinks, and do not mount the whole `sources` root, because that would invalidate the cache of existing layers whenever any source is added.
 
 ## System Development Packages