[backend] feat(service-account): implement the new token in the lifecycle of the agent and implant, and clean up the previous usage. (#5768)

[EvaE-Filigran]

Proposed changes

Backend

• Add getTokenUserServiceAccountByTenant() to ServiceAccountPrivilegeService — resolves the service account token for a given tenant, throwing if the account is missing or has an unexpected token count
• Tighten getUserServiceAccountByTenant() to only return a user that has exactly one token (guards against partially-provisioned accounts)
• Inject ServiceAccountPrivilegeService into OpenAEVExecutorContextService, OpenAEVExecutorIntegration, and OpenAEVExecutorIntegrationFactory so that executor command generation uses the tenant-scoped service token instead of the global admin token
• Update ExecutorApi agent installer endpoint:
  • Remove {token} path variable — the token is now resolved server-side from the service account
  • Replace TokenRepository dependency with ServiceAccountPrivilegeService
• Add a temporary overload ExecutorHelper.replaceArgs(..., token) (marked todo remove) to support the transition period while all executors are migrated off the admin token
• Mark the admin token usage in OpenaevImplantCommandBuilder.CommandVars with the same todo remove annotation

Frontend

• Remove userToken prop and MeTokensHelper usage from Agents.tsx and InstructionSelector.tsx — the token is no longer passed through the UI
• Update buildInstallationUrl() to drop the token segment from the installer URL path (/session-user/{token} → /session-user)
• Remove MeTokensHelper interface from helper.d.ts
• Remove the now-unused meTokens dispatch call

Testing Instructions

1. Navigate to Settings → Agents and open the agent installer wizard for OpenAEV.
2. Verify the installer command/URL is generated correctly without requiring a user token in the URL
3. Trigger a real inject execution via the OpenAEV agent/implant and confirm the agent authenticates successfully using the service account token

Related issues

• Closes [Service Accounts] US.2 — Auto-provision service account on tenant creation with correct group/role/capabilities #5769

Checklist

• I consider the submitted work as finished
• I tested the code for its functionality
• [] I wrote test cases for the relevant uses case
• I added/update the relevant documentation (either on github or on notion)
• Where necessary I refactored code to improve the overall quality
• For bug fix -> I implemented a test that covers the bug

[EvaE-Filigran]

The tests will be added.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 25 out of 26 changed files in this pull request and generated 12 comments.

Comments suppressed due to low confidence (1)

openaev-api/src/main/java/io/openaev/service/TenantGroupService.java:126

• issue (blocking): updateGroupRoles resolves roles via roleService.findById(id) which is not tenant-scoped. A caller can provide a role ID from another tenant and (if it exists) associate it to a group in the current tenant, risking cross-tenant privilege leakage. Use the tenant-scoped lookup (findByIdInTenant) instead.

    List<Role> roles =
        input.getRoleIds().stream()
            .map(
                id ->
                    roleService

[RomuDeuxfois]

Test 🆗