chore: adopt upstream v1.45.0

[marcorivm]

Adopts upstream v1.45.0 per the decisions in docs/upstream-sync/reviews/2026-08-05-v1.45.0.md (#9). 83 files, but the review surface is the ~10 files listed below — the rest is upstream's own code arriving.

Merged onto the project-lifecycle stack rather than bare v1.44.0, so the real conflict set was 7, not the 6 the original review measured — navigation.ts joined, because the project cookie now lives there.

The blocker, fixed

Upstream's new fail-closed check in connect.rs::resolve_access_token withholds a credential whenever a connection carries a session policy and neither a token scoper nor a request guard exists. try_refresh_credentials is a stub here, so ee_apps::has_request_guard returning false would have silently stopped every resource-scoped GitHub and Dropbox connection from injecting anything — with cargo test still green, because scope.rs's tests never reach resolve_access_token.

pub(crate) fn has_request_guard(provider: &str) -> bool {
    matches!(provider, "github-app" | "github" | "dropbox")
}

The list mirrors evaluate_scope's dispatch exactly — anything else falls to Indeterminate → Blocked, so claiming a guard for it would assert enforcement that doesn't exist. Two new tests guard both directions, since nothing in CI caught this class of regression before.

Three files merged cleanly and wrongly

Two were predicted by the review:

• api/keys.ts — two projects: keys in one object literal (TS1117; queryKeys.projects.detail would have become undefined)
• resource-scope.tsx — duplicate granularAccessConfigs import

One was not predicted: gateway/mitm.rs bound provider twice in a single destructuring pattern — upstream added provider: _, the fork already had provider: prov, which feeds apply_resource_scope. A hard compile error, but it carried no conflict markers either. Worth folding into the skill's gotchas.

Conflicts resolved as unions

Wherever upstream's signature is a superset of the fork's, I took upstream's:

file	resolution
api/projects.ts, use-projects.ts, api/keys.ts	The fork's slice-1 list() and upstream's arrived independently. Upstream's carries an optional organizationId override for the account-route picker, so existing callers keep working and gain the capability.
api/client.ts	Fork's ApiError + upstream's widened apiGet(path, init?) — what makes that override possible. Not added to the other verbs; nothing calls them that way.
navigation.ts	Project cookie beside upstream's new DEFAULT_ORG_COOKIE, one definition each — exactly as docs/project-lifecycle.md anticipated.
gateway/hooks.rs	Upstream's refuse_empty_scope beside the budget gate; adjacent insertions, no overlap. Module doc now records why it's inert here.

resource-scope.tsx — the props are honoured, not just accepted

manage-permissions-dialog.tsx merged with no conflict passing readOnly and orgPolicy. Ignoring them would type-check and silently render org-granted grants as editable, with edits staying live during save. So readOnly is threaded into ScopeChecklist and ScopeTextList (neither had any disabled support), and orgPolicy disables out-of-boundary items with a stated ceiling.

Upstream's || readOnly early return is deliberately not copied — the dialog passes save.isPending, so the whole Resources block would blink out mid-save.

Deletions accepted

get-started-dialog (replaced by /install), app-permissions-reflection, permissions-list, agent-scope-select, withOrgPrefix. Verified zero dangling references.

Verification

cargo test -p onecli-gateway     # 615 passed (613 + 2 new)
pnpm --filter @onecli/api test   # 1205 passed
pnpm --filter @onecli/web test   # 13 passed — upstream's vitest harness, which the fork's web slices lacked
pnpm run check                   # 9/9 tasks

The review's own checklist: exactly one projects: key ✓, one granularAccessConfigs import ✓, zero dangling refs ✓, zero conflict markers ✓.

One fix needed on the way in: upstream gave listAgents a requestLog.groupBy aggregate, which the fork's api-key.test.ts mock had to learn.

Follow-up

docs/upstream-sync/state.json still says forkBase: v1.44.0 with this adoption pending. That file lives on #9's branch, which is a sibling of this stack rather than an ancestor, so it can't be updated from here — it needs a follow-up once #9 merges. The ee_apps scaffolding decisions (compose_resource_scope, scope_reaches_nothing) remain open as the review recorded.