[NeverENG]

Which issue or RFC does this PR close?

Refs #2460. This is the Core contract/authorization half; it does not close the issue. The Rust Executor/transport integration and actual-listener acceptance belong to the follow-up PR (built on the G3-0 foundation merged in #2499).

Rationale for this change

A Gateway-selected profile and a separately configured upstream URL cannot establish that Core checked the address to which transport sends. This PR exposes the endpoint from the same trusted Core profile that checked the final payload, rather than accepting a client-supplied destination or maintaining another URL authority.

What changes are included in this PR?

• An authorized service principal can request target_endpoint and target_protocol on an allowed before_send; ordinary checks, denied checks and blocked payloads do not disclose the endpoint. The caller needs both Scope-level gateway.invoke and scope.read. UDS alone does not grant this privilege.
• Include the exact target endpoint in Core's opaque send binding. Its configuration fingerprint covers the current target/policy even when the human-readable policy version is unchanged; the old request binding cannot correlate a response under changed configuration.
• Expose PowerContextClient.check_context(request, resolve_target=True) as an explicit Python SDK opt-in. The default sends no privileged header; a target-resolving allow without endpoint or protocol is rejected by the SDK. Update OpenAPI, checked-in Python/JS/Desktop generated contracts, the persisted authorization vocabulary review, and English/Chinese operational documentation. Existing calls without the optional header retain the prior response behavior; existing grants do not gain invocation implicitly. No persisted binding layout changes.
• Complete the response protocol enum for Core-supported jev-rerank; a regression test covers privileged HTTP and SDK consumption (previously the Server returned 422 while validating its own allowed response). The prior Desktop target-resolution and connection-identity contract qualification was measured at a pinned Server commit: the wheel built from pinned Server commit b6920bbf has 739 packaged runtime files matching that clean source commit, and the native probe passed four isolated SQLite Server modes with both disposable and bundled-product qualifications. Earlier qualification records retain their original source and contract identities; the newly merged head is not represented as a new Desktop product qualification. This does not claim installed UI, Windows, or external provider acceptance.

Are there any user-facing changes?

A new privileged opt-in check response and gateway.user Scope role / gateway.invoke action are available. Desktop only receives generated contract updates and a newly verified local-protocol compatibility profile; it does not acquire Gateway privileges. This PR alone does not change the current Gateway's send behavior. Revocation is enforced on new Core admissions; an already issued send admission is valid until valid_until and is not retroactively recalled.

How was this change tested?

• make check

• make contract-test (61 passed)

• uv run pytest tests/test_client.py tests/e2e/test_gateway_target_binding.py -q (43 passed)

• uv run pytest tests/e2e/test_gateway_target_binding.py tests/test_client.py tests/builtin/runtime/test_context_check.py tests/test_connection_identity.py -q (63 passed)

• uv run pytest tests/builtin/runtime/test_context_check.py tests/e2e/test_context_protection_transports.py -q (19 passed)

• make js-test; pnpm --dir desktop ipc:check; pnpm --dir desktop generate and generate:check with pinned generator/JDK (Node 24.16.0, pnpm 11.13.1; package engine requests Node 24.14.1)

• uv build --wheel --out-dir desktop/.artifacts/server-wheel; byte comparison of all 739 packaged runtime files against the pinned commit

• cargo build --locked --manifest-path desktop/src-tauri/Cargo.toml --example server_probe and uv run python desktop/tests/real_server.py in four independent local Server modes; rebuilt probe and reran with --product-qualification sqlite-core-target-identity-b6920bbf-v1 (all four passed)

• uv run pytest tests/test_desktop_fixture_qualification.py tests/e2e/test_gateway_target_binding.py -q (9 passed)

• cargo test --locked --manifest-path desktop/src-tauri/Cargo.toml bundled_qualification_allows_explicit_scope_browsing --quiet (targeted test passed)

• After merging upstream master c4c95e4: make contract-test; make check; make upgrade-policy-check; uv run pytest tests/e2e/test_gateway_target_binding.py tests/e2e/test_atomic_memory_reconciliation_retry.py tests/e2e/test_atomic_memory_fts_coverage.py tests/builtin/persistence/test_atomic_memory_search_scoring.py tests/builtin/persistence/test_oceanbase_atomic_memory_fts.py -q (58 passed, 10 skipped); pnpm --dir desktop lint, typecheck, test (212 passed), ipc:check; cargo test --locked --manifest-path desktop/src-tauri/Cargo.toml.

• The upstream master CI had seven failing reconciliation-source assertions (ee3c1ee) and an OceanBase test-double failure (c4c95e4); newer master commits now include their fixes. Conflict resolution retains the upstream versions of those tests rather than duplicate fixes.

• After merging master 7fef43d, make opendal-test (10 passed), make harness-check (306 passed), make contract-test, make check, make upgrade-policy-check, focused Core/Atomic tests (48 passed), Desktop lint/typecheck/UI tests (212 passed)/IPC check/Rust tests passed locally. Harbor 0.16.1 ACP runner now pins its own compatible SDK separately from Bub ACP server; locally verified the real runner imports and starts with the pinned SDK. Full Docker Harbor acceptance was not run locally (no Docker daemon); the new CI must establish it.

All local Desktop/native runs used macOS arm64, Python 3.14.5 and Rust 1.97.1; no real provider or installed-host acceptance is claimed.

AI usage statement

Implemented and reviewed with OpenAI Codex (GPT-6 Sol). The contributor inspected the resulting code and generated artifacts, ran the commands above, and retained responsibility for the change.

[CLAassistant]

All committers have signed the CLA.

[hidb4ai]

The Desktop IPC contract is out of sync with the new authorization variants and blocks Desktop validation. Please regenerate the missing artifact as noted inline.

[hidb4ai]

Re-reviewed 3961318. The previously reported Desktop IPC drift and host bundle drift are fixed; I have not reproduced a new correctness defect in the target-resolution changes.

The PR is still blocked for merge:

• Against current master e356ba2, git merge-tree reports conflicts in desktop/src-tauri/src/connections/compatibility.json, desktop/src-tauri/src/transport/operations.json, desktop/ui/src/generated/operations.ts, and release/upgrade-support.json. Please reconcile these and regenerate/validate the contracts and compatibility records against the combined OpenAPI.
• Windows candidate timed out after 300 seconds; upgrade preparation failed with ProcessLookupError in the cancellation test; Linux Desktop was cancelled after IPC validation. These need successful completion. I have not established the failures as regressions introduced by this patch; the upgrade cancellation case passed on local replay.

This remains a Core/SDK contract change; actual Gateway listener/transport target binding is still follow-up scope.

[hireview001]

• CI failed: CI result (failure).
• CI failed: desktop-validation / macos (macos-15-intel) (failure).
• CI failed: desktop-validation / windows (failure).
• CI failed: desktop-validation / macos (macos-15) (failure).
• CI failed: desktop-validation / linux (failure).
• CI failed: Main (failure). Failed steps: desktop-validation / linux / Run cargo test --locked --manifest-path src-tauri/Cargo.toml; desktop-validation / macos (macos-15) / Run cargo test --locked --manifest-path src-tauri/Cargo.toml; desktop-validation / windows / Run cargo test --locked --manifest-path src-tauri/Cargo.toml.

[hidb4ai]

please resolve conflicts