[ENHANCEMENT] Use unique UUIDs for Worker Locking in Event Producer instead of Trigger ID

[jcscottiii]

Currently, the EventProducer uses the incoming triggerID (from the Pub/Sub message ID or Cloud Event ID) as the workerID when acquiring the SavedSearchState lock in Spanner.

The Problem:
This approach is unsafe for distributed locking. If a worker process stalls (e.g., GC pause) and the lock expires, a second worker might pick up the retry of the same message. Since the triggerID is identical, the second worker acquires the lock with the same ID. If the first "zombie" worker wakes up, the database cannot distinguish between them because they share the same ID. This defeats the fencing token protection and could lead to data corruption (Split Brain) if the zombie worker overwrites the state.

The Solution:
The ProcessSearch method in the EventProducer must be updated to generate a new, random UUID (v4) at the start of every execution. This UUID should be used exclusively as the workerID for locking operations:

1. TryAcquireSavedSearchStateWorkerLock
2. PublishSavedSearchNotificationEvent (for the fencing check)
3. ReleaseSavedSearchStateWorkerLock

Acceptance Criteria:

• ProcessSearch generates a unique workerUUID.
• The workerUUID is passed to the lock acquisition method instead of triggerID.
• The workerUUID is passed to the publish/release methods to verify ownership.
• The triggerID is maintained for tracing and as the EventID for the resulting notification, but it is not used for the lock identity.