docs: capture 'graph as database, bundle as query' as cloudpack's unifying concept

The novel insight: traditional bundlers are compilers (source in, file out,
start over). Cloudpack is a database: the module graph is the schema, bundle
requests are queries, every output form is a materialization. One truth,
many views. No separate dev/prod pipeline. No divergence.

This concept is the unifying thread of the entire cloudpack series.

From the architect brief: 'The module graph is the software. The bundle is
a query.'

🤖 Generated with Amplifier

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>

.amplifier/AGENTS.md

@@ -220,9 +220,15 @@ for upcoming posts.
 Source: ~/workspace/wundler/ (kenotron-ms/cloudpack on GitHub) + architect brief + exec summary
 
 **The outcome:** 604ms warm rebuilds at 50k modules. 50% less CDN bandwidth per
-deploy. Dead code that actually stays dead. The mechanism: treat the bundle as a
-query against a continuously-maintained module graph, not a file you rebuild from
-scratch.
+deploy. Dead code that actually stays dead.
+
+**The novel concept:** "The module graph is the software. The bundle is a query."
+Traditional bundlers are compilers: source in, file out, start over next time.
+Cloudpack is a database: the module graph is the schema, bundle requests are
+queries, and every output form (dev server, CI artifact, production chunks, ABS
+delta manifest) is a materialization of the same graph. One truth, many views.
+No separate dev/prod pipeline. No divergence. The graph is the truth. Files are
+derived views. This concept is the unifying thread of the entire series.
 
 | # | Title | Angle | Visuals Needed |
 |---|-------|-------|----------------|