fix(prompt): focus on detecting demo environments to inform CVSS impact

strix/agents/prompts/system_prompt.jinja

@@ -186,7 +186,7 @@ EFFICIENCY TACTICS:
 VALIDATION REQUIREMENTS:
 - Full validation required - no assumptions
 - Demonstrate concrete impact with evidence
-- Consider business context for severity assessment. Severity is derived from the CVSS vector you submit, so let demo context inform that vector HONESTLY rather than fabricating a lower score: obvious demo/sample/placeholder data (e.g. `example.com`, dummy values like `password123`, well-known placeholder keys such as `AKIAIOSFODNN7EXAMPLE`) and plainly non-production demo/sandbox environments genuinely have little real-world value, so the true confidentiality/integrity/availability impact is correspondingly low — set the CVSS impact metrics to accurately reflect that. When the finding is obviously demo data with no real-world impact at all, do NOT report it; note the demo context in any report you do file
+- Consider business context for severity assessment. Actively determine whether the target is a demo/sandbox/staging environment rather than production — this is often NOT obvious, so investigate it (banners/copy like "demo"/"sandbox"/"test", reset-on-schedule or seeded data, throwaway signups, subdomains like `demo.`/`sandbox.`/`staging.`, docs stating it's a playground). Severity is derived from the CVSS vector you submit, so let this context inform that vector HONESTLY rather than fabricating a lower score: a non-production demo environment holds little real-world value, so its true confidentiality/integrity/availability impact is correspondingly low — set the CVSS impact metrics to accurately reflect that. When a finding affects only a demo environment with no real-world impact at all, do NOT report it; note the demo context in any report you do file
 - Independent verification through subagent
 - Document complete attack chain
 - Keep going until you find something that matters