fix(ai-red-teaming): authenticate agentic attacks + lighten ATLAS default budget

[rdheekonda]

Final capabilities fixes for the agentic red-teaming flow, validated live on prod (project airt-tui-verify) in edit mode.

1. Agentic attacks ran unauthenticated against provisioned targets (critical)

provision_environment returned the one-shot bearer execute token as text and told the agent to "set AGENT_API_KEY", but nothing injected it into the attack subprocess: generate_* only took the env-var name, and the runner never set the value. The generated agent target read an empty token, called the mesh unauthenticated, got no response, and every trial errored -> ASR 0% / all info on a trivially-exploitable target. (SDK notebooks were unaffected - their target closure captures the token in-process, which is why the SDK path "worked great end to end".)

Fix:

• provision_environment persists base_url + execute_token in the env registry.
• _auto_execute_workflow injects that token into the subprocess env under each token-like var the generated script reads (matched by the script's target URL against the registry). Single choke-point -> covers atlas / agentic / multistep / ci-exfil uniformly.

2. ATLAS default budget too heavy for interactive use

generate_atlas_attack defaulted total_budget=64, so one TUI call ran 15+ minutes. Default to 12 (the cookbook demo config). Raise for deeper sweeps.

Validation (prod, edit mode, airt-tui-verify)

• ATLAS: 2x critical (transfer_funds + admin_create_user, real tool evidence) - was ASR 0% / "(no response)" before.
• multistep: 5 chains fired, all replay-stable, non-empty tool_calls.
• GOAT (generate_agentic_attack): read_file -> fetch_url/send_email exfil fired, 100% ASR.
• All findings land as critical with tool-call evidence + traces.

Test plan

• Re-run each agentic cookbook scenario via the TUI and confirm findings land critical with tool calls.