fix: apply --url can submit to a completely different job than the one targeted

[sebastianmukuria]

The bug

acquire_job's target-url lookup builds its fallback LIKE pattern by stripping the query string:

like = f"%{target_url.split('?')[0].rstrip('/')}%"
WHERE (url = ? OR application_url = ? OR application_url LIKE ? OR url LIKE ?)

On indeed and linkedin the query string is the job identity (?jk=…, currentJobId=…), so the pattern collapses to %indeed.com/viewjob% — which matches every indeed job in the database. Since the exact and LIKE conditions are OR'd in one query with LIMIT 1 and no ORDER BY, SQLite returns an arbitrary matching row.

Impact: running applypilot apply --url <job A> can silently select job B and submit the candidate's application to a different company. Observed in the wild: targeting one indeed posting ran a different company's application twice in a row.

The fix

1. Exact match on url / application_url first.
2. Only if nothing matches exactly, fall back to a LIKE that tolerates scheme and trailing-slash variants of the same URL — with the query string preserved.
3. No match → None (the caller reports no job found), never someone else's job.

Three regression tests included (tests/test_target_url_match.py): query-string identity is respected, unknown URLs return None rather than falling back, and scheme/trailing-slash variants still resolve.

🤖 Generated with Claude Code