feat: browser session persistence, auto-screenshots, context optimization, user cleanup

Browser tool:
- Session-persistent Chrome tab (same tab reused across all calls in a pentest)
- Auto-screenshot on every navigate and click (stored in attack chain for report)
- Fill uses CDP Input.insertText (fixes WebSocket corruption on special chars)
- Switched from browserless/chromium to chromedp/headless-shell (stable WS)

Context window optimization:
- Strip screenshot_base64 from LLM conversation (kept in DB for report)
- Truncate HTML to 2KB, page text to 1.5KB in LLM messages
- Cap element/link arrays at 15 items
- SAST triage: batch 30 findings per LLM call instead of all at once

Report improvements:
- Auto-embed screenshots in attack chain timeline (navigate + click nodes)
- Cover page shows best app screenshot
- Attack chain phases capped at 8 (no more 20x "Final")

User cleanup:
- TestUserRecord model tracks created test users per session
- cleanup.rs: Keycloak (Admin REST API), Auth0 (Management API), Okta (Users API)
- Auto-cleanup on session completion when cleanup_test_user is enabled
- Env vars: KEYCLOAK_ADMIN_USERNAME, KEYCLOAK_ADMIN_PASSWORD

System prompt:
- Explicit browser usage instructions (navigate → get_content → click → fill)
- SPA auth bypass guidance (check page content, not HTTP status)
- Screenshot instructions for evidence collection

Other:
- Pin mongo:7 in docker-compose (mongo:latest/8 segfaults on kernel 6.19)
- Add deploy/docker-compose.mailserver.yml for Postfix + Dovecot

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

compliance-agent/src/pentest/prompt_builder.rs

@@ -285,15 +285,34 @@ impl PentestOrchestrator {
 1. Start by running reconnaissance (recon tool) to fingerprint the target and discover technologies.
 2. Run the OpenAPI parser to discover API endpoints from specs.
 3. Check infrastructure: DNS, DMARC, TLS, security headers, cookies, CSP, CORS.
-4. Based on SAST findings, prioritize testing endpoints where vulnerabilities were found in code.
-5. For each vulnerability type found in SAST, use the corresponding DAST tool to verify exploitability.
-6. If vulnerable dependencies are listed, try to trigger known CVE conditions against the running application.
-7. Test rate limiting on critical endpoints (login, API).
-8. Check for console.log leakage in frontend JavaScript.
-9. Analyze tool results and chain findings — if one vulnerability enables others, explore the chain.
-10. When testing is complete, provide a structured summary with severity and remediation.
-11. Always explain your reasoning before invoking each tool.
-12. When done, say "Testing complete" followed by a final summary.
+4. If the target requires authentication (auto-register mode), use the browser tool to:
+   a. Navigate to the target — it will redirect to the login page.
+   b. Click the "Register" link to reach the registration form.
+   c. Fill all form fields (username, email with plus-addressing, password, name) one by one.
+   d. Click submit. If a Terms & Conditions page appears, accept it.
+   e. After registration, use the browser to navigate through the application pages.
+   f. **Take a screenshot after each major page** for evidence in the report.
+5. Use the browser tool to explore the authenticated application — navigate to each section,
+   use get_content to understand the page structure, and take screenshots.
+6. Based on SAST findings, prioritize testing endpoints where vulnerabilities were found in code.
+7. For each vulnerability type found in SAST, use the corresponding DAST tool to verify exploitability.
+8. If vulnerable dependencies are listed, try to trigger known CVE conditions against the running application.
+9. Test rate limiting on critical endpoints (login, API).
+10. Check for console.log leakage in frontend JavaScript.
+11. Analyze tool results and chain findings — if one vulnerability enables others, explore the chain.
+12. When testing is complete, provide a structured summary with severity and remediation.
+13. Always explain your reasoning before invoking each tool.
+14. When done, say "Testing complete" followed by a final summary.
+
+## Browser Tool Usage
+- The browser tab **persists** between calls — cookies and login state are preserved.
+- After navigate, the response includes `elements` (links, inputs, buttons on the page).
+- Use `get_content` to see forms, links, buttons, headings, and page text.
+- Use `click` with CSS selectors to interact (e.g., `a:text('Register')`, `input[type='submit']`).
+- Use `fill` with selector + value to fill form fields (e.g., `input[name='email']`).
+- **Take screenshots** (`action: screenshot`) after important actions for evidence.
+- For SPA apps: a 200 HTTP status does NOT mean the page is accessible — check the actual
+  page content with the browser tool to verify if it shows real data or a login redirect.
 
 ## Important
 - This is an authorized penetration test. All testing is permitted within the target scope.