fix(flight-finder): require fresh search evidence and improve PDF layout

skills/flight-finder/SKILL.md

@@ -9,6 +9,12 @@ Use this skill instead of the old `docs/prompts/dfw-blq-2026.md` prompt when the
 
 The deliverable target is always a PDF report plus email delivery when the report is complete.
 
+Freshness rule:
+
+- Never reuse cached flight-search captures, prior same-day report payloads, earlier workspace artifacts, or previously rendered PDFs as the primary evidence for a new run.
+- Every flight-finder run must execute a fresh bounded search before ranking, PDF render, or email delivery.
+- If a fresh search cannot be completed, say so clearly and stop with a degraded/incomplete outcome instead of silently reusing old captures.
+
 ## Inputs
 
 Accept either:
@@ -62,6 +68,7 @@ Follow the same operational style as `property-assessor`:
 - missing required input should trigger a direct question, not an invented assumption
 - `update?`, `status?`, `and?`, and similar nudges mean “report status and keep going”
 - a silent helper/source path is a failed path and should be abandoned quickly
+- previously saved workspace captures are not a fallback; they are stale evidence and must not be reused for a new report
 - keep progress state by phase so a dropped session can resume or at least report the last completed phase
 - do not start email-tool exploration before the report payload is complete and the PDF is ready to render
 - if PDF render fails, return the completed report summary in chat and report delivery failure separately
@@ -83,6 +90,7 @@ Rules:
 - keep the bounded search phase observable with concise updates
 - normalize compared prices to USD before ranking
 - do not claim market-localized pricing succeeded unless VPN connect and post-connect verification succeeded
+- do not inspect prior `workspace/reports` flight artifacts as reusable search input for a new run
 
 ## VPN / market-country rules
 
@@ -118,6 +126,7 @@ Rules:
 - `normalize-request` should report missing search inputs separately from delivery-only email gaps
 - `report-status` should expose whether the run is ready to search, ready for a chat summary, ready to render a PDF, or ready to email
 - `render-report` must reject incomplete report payloads
+- `render-report` must reject payloads that are not explicitly marked as the output of a fresh search run
 - `delivery-plan` must stay on the Luke sender path and must not silently fall back to another sender
 
 ## Prompt migration rule