Disable session row actions when access key differs from current user's keypair

[yomybaby]

Background

FR-2586 (PR #7409) improved the app launch failure path by replacing a raw 404 manager error with a friendly notification explaining the likely access-key mismatch and how to recover.

The same root cause — the user has switched to a different keypair after the session was created — also breaks other row-level actions on the session list:

• View container logs → 403 Forbidden, "Only admins can perform operations on behalf of other users."
• Terminate session → same 403 with the same message.

Today both buttons appear enabled and the user only discovers the problem after clicking, at which point they get a backend error that reads as if they don't own the session (they do — they're just acting under a different access key).

Approach

Since the session row already carries access_key in the SessionActionButtonsFragment GraphQL fragment, we can detect the mismatch on the client and prevent the action upfront:

1. In react/src/components/ComputeSessionNodeItems/SessionActionButtons.tsx, compute isAccessKeyMismatch = session.access_key !== baiClient._config.accessKey.
2. When isAccessKeyMismatch is true, disable the logs and terminate buttons (in addition to whatever existing isActive / isOwner checks already gate them).
3. Replace the tooltip title with an explanatory message when the mismatch is the reason for disabling, e.g. "This session was created under a different access key. Switch back to that access key to view logs / terminate the session."
4. Apply the same logic to any other action button on the row that hits a per-session API path requiring the original access key. At minimum, audit: appLauncher, terminal, containerCommit, sftp. (App launch already has a sane post-failure message from FR-2586 — preemptive disable is still preferable.)

Notes / Scope

• Admins can act on behalf of other users — but the action buttons live on the user's own session list view, not the admin sessions page. The session list query is already filtered to the current user, so a mismatch here always means "I'm currently keyed in as access key B but this row was created under access key A." Keep the check naive (string equality on access_key) — do not branch on role.
• Do not touch the existing FR-2586 friendly error in useBackendAIAppLauncher.tsx; this issue is about the other action buttons (logs, terminate, …) on the same row.
• i18n: add one new key, populate all 22 locales, follow the existing session.* namespace.

Acceptance Criteria

• When the current access key differs from a session's access_key, the terminate and logs buttons on that session row are disabled.
• Hovering the disabled buttons shows a tooltip explaining the access-key mismatch and the recovery path.
• Other applicable session row actions (appLauncher, terminal, containerCommit, sftp) are audited and disabled in the same condition where the API call would otherwise return 403.
• No regression on sessions whose access_key matches the current keypair — all buttons behave exactly as today.
• All 22 locales updated for the new key.
• bash scripts/verify.sh passes.

JIRA Issue: FR-2899