fix(security): require non-spoofable signal for auto-verification approval

[Neziahtech]

Closes #67

PR Description
Why this matters now
Sourcegraph — sorry, wrong context — the platform's core value proposition is tamper-evident proof-of-impact. Today, auto-approval is driven entirely by client-supplied metadata (EXIF/GPS), which the client's own device controls. That's a trust-boundary violation: we're treating attacker-controlled input as a security signal.

Problem
autoVerify (src/services/verificationService.ts:15-115) computes a weighted score from:

Signal Weight
gps_location 0.4
photos_present 0.15
photo_quality 0.1
photo_recency 0.05
timestamp_not_forged 0.05
photo_not_duplicate 0.1
task_not_expired 0.2

Auto-approve threshold is ≥ 0.7.
Every one of these signals is derivable from client-controlled EXIF/GPS data. An attacker who controls the device (or just edits EXIF with a script) can satisfy gps_location + photo_recency + timestamp_not_forged + photos_present + photo_quality = 0.8, clearing the threshold with zero cryptographic proof the photo was taken at the claimed location/time. task_not_expired and photo_not_duplicate add no resistance either — both are trivially satisfiable by a motivated forger.

Net effect: the auto-verify path can be fully spoofed with a single crafted upload. No device attestation, no server-side capture, no hash chain — just metadata a client wrote itself.

What this PR does
Introduces at least one non-spoofable signal as a hard requirement for auto-approval, separate from the weighted score. Candidate approaches (pick one or combine, see discussion):

Signed device attestation — mobile client signs capture metadata (GPS, timestamp, photo hash) with a device-bound key (e.g., Play Integrity API / iOS DeviceCheck) at time of capture; server verifies the signature and freshness of the attestation before the score is even computed.
Server-side capture — photo is captured/uploaded through a flow where the server (not the client) is the source of truth for timestamp and, where feasible, coarse location (e.g., IP-based sanity check against claimed GPS).
Watermark / hash chain — server issues a nonce/challenge at task-start; client must embed it (visibly or steganographically) in the photo before upload, proving the photo was captured after and in response to that specific task instance, not reused/pre-staged.
At minimum, this PR ensures EXIF-only signals cannot reach auto-approve on their own, even if a non-spoofable check isn't fully implemented yet — i.e., cap the max achievable score from spoofable signals below 0.7, and gate final approval on the non-spoofable check passing.

Scope of changes
src/services/verificationService.ts — restructure autoVerify so approval requires nonSpoofableSignalPassed === true AND weighted score ≥ threshold (not score alone).
src/services/photoService.ts — add capture-attestation/nonce/hash-chain plumbing as needed by chosen approach.
src/workers/verificationWorker.ts — update worker to fetch/validate the new signal and pass through to autoVerify.

Acceptance Criteria
Auto-approval requires at least one defined non-spoofable signal in addition to the existing weighted score.
Red-team test: a crafted EXIF/GPS-only submission (no valid attestation/nonce/hash-chain) cannot reach auto-approve, regardless of how favorably the other fields are spoofed.
Existing legitimate capture flow still passes auto-verify without added friction beyond the new signal.
False-positive/false-negative rate on the non-spoofable check documented and within agreed tolerance (baseline TBD in review).
Unit tests covering: (a) valid attestation + good score → approve, (b) spoofed metadata + no attestation → reject/fallback to manual, (c) missing attestation entirely → reject/fallback to manual.

[cybermax4200]

The ci checks are failing, please kindly fix them. Also resolve the merge conflicts

[cybermax4200]

Fix workflow