fix(app): honor project permission overrides for unloaded sessions - #55178

Issue for this PR

Closes #55176

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This fixes project-level permission auto-accept overrides for sessions that the app has not loaded. When the app-wide default is On and a project's override is Off, a permission request from an unknown session currently receives an automatic once reply. After this change, the app first obtains that session's project ID and leaves the request pending when the project's setting requires manual approval.

The failure comes from the early return in consider() in packages/app/src/session/requests/auto-approve.ts. Its covers(undefined) condition checks the global default without knowing the request's project. If that default is On, the function calls approve() immediately. For an unknown session, approve() cannot recover a project ID from the local store either, so its final settings check also uses the global default. The explicit project override is never considered. Cached sessions do not exhibit this problem because their project ID is already available.

The production change removes that global-default shortcut. The cached-session branch continues to call approve() directly. Every unknown session instead follows the session-get branch that already exists, and the returned project ID is passed to approve(). That function remains responsible for checking the server-scoped project setting, suppressing duplicate replies, and respecting disposal and retry behavior. The fix therefore changes when the project is resolved rather than introducing a second policy implementation.

The observable result is consistent approval behavior before and after a session is opened. An explicit Off override leaves its request pending, while an On project still receives an automatic reply. Restoring a project to the default continues to approve requests when the default is On. The additional work is a session GET for a request whose session metadata is absent; requests from cached sessions keep the existing direct path.

The regression coverage extends the existing project-override case in the multi-server keeper. After the initial settings sweep, it adds two sessions without publishing events that would populate the app's session cache. One belongs to an On project and one to an Off project. It then delivers permission events, checks the exact automatic replies, confirms that the blocked session was fetched, and opens that session to verify that the permission remains visible. Finally, it restores the Off project to the default and checks that all remaining requests are released. This covers the missing cache state within the existing owner of project and server approval behavior.

How did you verify your code works?

The complete e2e/regression/multi-server.spec.ts keeper passes all five cases. The extended override case checks exact outgoing replies and confirms that the Off project's request remains available for manual approval. The other cases also exercise remote-server settings, unfocused sessions and children, reconnect sweeps, and permissions discovered when a session opens.

Local verification included:

• The five-case multi-server keeper, run from packages/app with one worker using the shared mock-server and SSE harness. Browser execution used the installed Chromium headless-shell build 1200 through a temporary local configuration; the project's default browser build is 1217.
• bun run typecheck in packages/app, which passed. The tracked custom-element declaration symlink was temporarily materialized for the Windows checkout during this check and restored afterward.
• Focused oxlint checks on the production file and keeper, with zero warnings and zero errors, and git diff --check.

To exercise the same keeper from packages/app:

bun run test:e2e -- e2e/regression/multi-server.spec.ts --workers=1

Screenshots / recordings

There is no visual layout change. The keeper verifies that the blocked project's permission remains visible in its session and that the outgoing replies match the effective settings.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR