Fix thread-safety in assistant agent run loop

[adamcohenhillel]

Several fields in the agent run loop are shared across UI, agent, and overlay threads without synchronization.

Findings

• mAgentRunGeneration — non-volatile int, written on the UI thread and read from the agent thread in isCancelled(). AssistantActivityBackend.java:216, 3291.
• Pending-confirmation state (mPendingActionId, related fields) — shared across UI thread, static overlay entry (:100), and agent threads with no synchronization. :3352.
• OpenPhoneAgentJobScheduler.isCancelled() hardcodes false (:142-144) — background jobs cannot be stopped once started.

Fix

• Convert mAgentRunGeneration to AtomicInteger (or make it volatile + never increment across threads).
• Guard pending-confirmation fields with a single lock or move them into an immutable snapshot object swapped via an AtomicReference.
• Wire OpenPhoneAgentJobScheduler.isCancelled() to a real cancellation signal from the job manager.

Small, focused change — good good first issue for someone comfortable with Java concurrency.

Size: S

[faiqq7]

Opened a fix in #103 — converted mAgentRunGeneration to AtomicInteger and wired up real job cancellation in OpenPhoneAgentJobScheduler. I also traced the pending-confirmation fields you flagged and couldn't confirm an actual race on them (all access appears UI-thread-confined) — details and reasoning in the PR description, flagging in case I missed a call path. Also couldn't run the Java compile check locally (no Android SDK).