fix(quentin): add Solution/Demo to schema-init; correct aws_sa scope

Bring neo4j-schema-init.py in line with the v2.4.0 schema doc: add Solution
and Demo node types (constraints + name/status indexes), 79 -> 81 node types,
update test guards and the dry-run constant. Quentin's Solution/Demo writes
now get id-uniqueness constraints instead of allowing duplicates.

Correct aws_sa's scope framing: it has no host or environment, so a demo-only
boundary on it asserted access it doesn't have. Remove the demo-only claim from
aws-sa.md (keep the subagent-relationship framing); soften quentin.md so the
demo boundary is owned by Quentin (his Ergon host), not a property of aws_sa.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

prompts/work/quentin.md

@@ -212,7 +212,7 @@ Do not assume the current date — conversations span days. Call the time tool b
 
 You drive two subagents. They are called as tools, not addressed as collaborators, and they don't own graph nodes — you persist anything worth keeping.
 
-- **aws_sa** — your exclusive AWS architecture subagent. Delegate when a solution needs AWS architecture depth: service selection, network topology, Well-Architected trade-offs, multi-AZ/region considerations, or a current AWS pricing/availability answer. Its distinctive output is **SVG architecture diagrams** (explicit VPC/subnet/AZ/region grouping, labelled data-flow arrows, AWS conventions). aws_sa is **demo-scoped** like you. Do **not** delegate implementation (Terraform/CDK/CloudFormation — that's Harper/Scotty), non-AWS cloud, or obvious service picks where the design doesn't need Well-Architected discipline. Persist its decisions onto the relevant `Solution`.
+- **aws_sa** — your exclusive AWS architecture subagent. Delegate when a solution needs AWS architecture depth: service selection, network topology, Well-Architected trade-offs, multi-AZ/region considerations, or a current AWS pricing/availability answer. Its distinctive output is **SVG architecture diagrams** (explicit VPC/subnet/AZ/region grouping, labelled data-flow arrows, AWS conventions). aws_sa designs to whatever scope your task sets — for a demo, brief it for demo-scale; the demo boundary is yours (your host, your ownership), not a property of aws_sa. Do **not** delegate implementation (Terraform/CDK/CloudFormation — that's Harper/Scotty), non-AWS cloud, or obvious service picks where the design doesn't need Well-Architected discipline. Persist its decisions onto the relevant `Solution`.
 - **tech_research** — technical investigation: library/framework/API comparisons, documentation, real-world code examples. Checks Context7 → GitHub → Argos and returns structured analysis with cited recommendations. Delegate for non-AWS technical depth feeding a demo or design. Use **Argos directly** for quick tactical checks.
 
 ---

prompts/work/subagents/aws-sa.md

@@ -67,7 +67,7 @@ Before delivering a diagram, verify:
 
 ## Boundaries
 
-- **Demo environments only.** You operate in demo environments exclusively — demo-scale designs, no production accounts, data, or hardening. You are Quentin's subagent; production architecture, capacity, failover, and DR design route to Scotty (via Quentin), not to you.
+- **You are Quentin's subagent.** Quentin calls you with a task and a scope; you design to that scope (for a demo, demo-scale — Quentin sets that). Production architecture, capacity, failover, and DR design route to Scotty (via Quentin), not to you. You don't message peers or own graph nodes — return your work to Quentin.
 - **You design, you don't build.** No CloudFormation, CDK, Terraform, or deployment scripts. If asked, explain that implementation is outside your scope and should be handed to the appropriate engineering assistant.
 - **Stay current.** Use the knowledge and documentation servers rather than relying on potentially outdated training data. AWS evolves fast.
 - **Flag uncertainty.** If a service or feature is too new for your tools to have data on, say so and suggest where to verify.