[FIX] Add fallback_directive field to ToolGuardrailDecision for non-retryable failures (child of #744)

[Lexus2016]

Parent issue

#744 — loop_guard fallback directive after non-retryable failures

Problem

When the loop_guard detects a non-retryable failure (e.g., "command not found", "permission denied"), it blocks retries but does not emit a fallback directive — the agent gets no structured guidance on what to do instead.

Proposed change (this slice only)

Add a fallback_directive field to ToolGuardrailDecision in agent/tool_guardrails.py:

1. When a non-retryable failure is detected, populate fallback_directive with a structured hint
2. The directive describes the recommended alternative action (e.g., "use search_files instead", "use vision_analyze for binary files", "install missing package first")
3. Emit this field in the guardrail decision output so the agent loop can consume it

Scope

• Add the field to the dataclass/model
• Populate it in the existing non-retryable failure detection paths
• Estimated diff: ~30-60 lines
• Files: agent/tool_guardrails.py, possibly agent/tool_diagnostics.py

Dependencies

• None (field addition is self-contained; wiring into the agent loop is a separate child issue)

Testing

• Unit test: non-retryable failure produces a non-empty fallback_directive
• Unit test: retryable failure produces empty/null fallback_directive

[Lexus2016]

Re-opened by realized-impact gate: post-merge verdict was regressed — the fix did not reduce the target signal in real sessions. Needs a focused regression before re-closing. (Introspection cycle 2026-07-18)