fix(jira): prevent CLI webhook-secret updates from losing refreshed OAuth tokens

## Problem

`bgagent jira setup` and `bgagent jira update-webhook-secret` read the shared per-tenant OAuth bundle, modify `webhook_signing_secret`, and write the complete bundle back. A concurrent Lambda refresh in `cdk/src/handlers/shared/jira-oauth-resolver.ts` can rotate `refresh_token` between the CLI read and write, allowing the CLI to overwrite the newly rotated token with a stale value and break subsequent Jira authentication. The existing `invite-user` update path has the same read-modify-write pattern.

This was identified as a non-blocking review finding on #710. It is intentionally separate because Secrets Manager `PutSecretValue` does not provide a simple version-conditioned compare-and-swap; `ClientRequestToken` provides idempotency, not protection against overwriting a concurrently created version.

## Acceptance criteria

- Define a concurrency-safe ownership/update strategy for mutable Jira OAuth bundles.
- Prevent CLI updates from replacing a `refresh_token` rotated after the CLI read.
- Preserve webhook and Forge app-actor fields across OAuth refresh and CLI updates.
- Add a test that interleaves a Lambda refresh with each affected CLI update path.
- Document retry/recovery behavior when a concurrent update is detected.

Start with cdk/src/handlers/shared/jira-oauth-resolver.ts and the CLI entry points for bgagent jira setup, update-webhook-secret, and invite-user to map their shared OAuth bundle updates. Add interleaving tests for a Lambda refresh with each CLI path, verify refresh_token, webhook, and Forge fields are preserved, and document retry or recovery behavior when a concurrent update is detected.

Written by the indexing model from the issue text.