Declare the documentation's structure in a source file

src/documentation.cpp is the documentation loading source: it carries no
code and names each document that the generated reference contains, in
order, by page label. The labels are declared on each markdown file's
first heading. The build configuration lists the files as Doxygen inputs
and nothing more, so the structure of the documentation and the
mechanics of generating it are separate.

The hand-maintained document index at the end of OVERVIEW.md is gone,
along with the last references to markdown files by filename in the
public header. The document list exists in one place.

The docs target clears its output and scratch directories on every run.
Doxygen keeps output files it judges unchanged, so a run over a
populated scratch directory carried pages forward from earlier ones, and
removed sections survived in the generated HTML and PDF after their
source was edited.

docs/BUILD.md

@@ -1,4 +1,4 @@
-# Building libdpm-core.so and the dpm Binary
+# Building libdpm-core.so and the dpm Binary {#build}
 
 ## Prerequisites
 

docs/CONSUMERS.md

@@ -1,4 +1,4 @@
-# Consuming libdpm-core.so
+# Consuming libdpm-core.so {#consumers}
 
 Programs link libdpm-core.so as an ordinary shared library dependency — the same way they link any other library — to reach the package manager in-process: build systems, installers, image builders, system tooling, and foreign-language bindings all use the library the `dpm` binary is built on. A program holding a default context is working against system configuration, the system module path, the system tree, and system locking, the same environment the installed `dpm` binary sees.
 

docs/DESIGN.md

@@ -1,4 +1,4 @@
-# DPM — Dark Horse Package Manager: Design
+# DPM — Dark Horse Package Manager: Design {#design}
 
 ## Constraints
 

docs/DOCUMENTATION.md

@@ -1,4 +1,4 @@
-# Generating the Code Reference
+# Generating the Code Reference {#documentation}
 
 When Doxygen is present, the build offers a `docs` target that generates the API and source reference from the documentation comments carried in the headers and sources. It opens on a front page declared in `include/dpm/core.h`, followed by the module contract, then the namespace, class, and file reference.
 

docs/MODULES.md

@@ -1,4 +1,4 @@
-# Developing DPM Modules
+# Developing DPM Modules {#modules}
 
 A DPM module is one shared object in the module directory. libdpm-core.so loads it, validates it completely, and dispatches commands to it on behalf of whatever asked — the `dpm` binary, a build system, or another module. This document covers writing, building, testing, and installing a module.
 

docs/OVERVIEW.md

@@ -1,4 +1,4 @@
-# DPM — An Overview
+# DPM — An Overview {#overview}
 
 ## What DPM Is
 
@@ -178,11 +178,3 @@ Every other module is developed against libdpm-core.so and lives outside this re
 4. Writes flow down, never sideways: a layer mutates the system only through the layer beneath it, in-process through mediated calls.
 5. A module is either fully valid or not loaded — no partial states, no consumer-side defense.
 6. Anything a linked program can redirect, a shell user can redirect too.
-
-## Further Reading
-
-- **DESIGN.md** — the full design specification
-- **CONSUMERS.md** — linking libdpm-core.so and driving it from a program
-- **MODULES.md** — writing, building, testing, and installing a module
-- **BUILD.md** — building, testing, and installing libdpm-core.so and the `dpm` binary
-- **DOCUMENTATION.md** — generating the code reference