fix(seer): Increase lock duration for issue summary generation (#103477)

Fixes
[SENTRY-5BCJ](https://sentry.io/organizations/sentry/issues/6969105720/).
The issue was that: Lock duration (10s) is shorter than the downstream
API call latency (18s+), causing lock expiry before operation
completion.

- Increased the lock duration for issue summary generation from 10
seconds to 40 seconds.
- This ensures the lock doesn't expire while the Seer request is still
pending, preventing lock release failures.


This fix was generated by Seer in Sentry, triggered automatically. 👁️
Run ID: 2145868

Not quite right? [Click here to continue debugging with
Seer.](https://sentry.io/organizations/sentry/issues/6969105720/?seerDrawer=true)


### Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated
in the State of Delaware in 2015 as Functional Software, Inc. and is
gonna need some rights from me in order to utilize my contributions in
this here PR. So here's the deal: I retain all rights, title and
interest in and to my contributions, and by keeping this boilerplate
intact I confirm that Sentry can use, modify, copy, and redistribute my
contributions, under Sentry's choice of terms.

---------

Co-authored-by: seer-by-sentry[bot] <157164994+seer-by-sentry[bot]@users.noreply.github.com>
Co-authored-by: Kush Dubey <[email protected]>

Author: seer-by-sentry[bot]

src/sentry/seer/autofix/issue_summary.py

@@ -459,7 +459,7 @@ def get_issue_summary(
 
     cache_key = get_issue_summary_cache_key(group.id)
     lock_key, lock_name = get_issue_summary_lock_key(group.id)
-    lock_duration = 10  # How long the lock is held if acquired (seconds)
+    lock_duration = 40  # How long the lock is held if acquired (seconds). request timeout is 30 sec
     wait_timeout = 4.5  # How long to wait for the lock (seconds)
 
     # if force_event_id is set, we always generate a new summary