Unify secure-gateway URL wrappers: inference_models proxy builder lacks idempotence guard and drops gateway base path

[alexnorell]

Follow-ups from the secure-gateway audit on #2658 (out of that PR's scope):

1. roboflow_secure_gateway_proxy_url_builder (inference_models/inference_models/weights_providers/roboflow.py) diverges from wrap_url (inference/core/utils/url_utils.py):

• No idempotence guard: an already-wrapped download_url gets double-proxied ({gateway}/proxy?url={gateway}%2Fproxy%3Furl%3D...). wrap_url gained this guard in Fix outbound calls that bypass the secure gateway #2658.
• Base-path handling differs: the builder uses urlsplit scheme+netloc only, dropping any path on the gateway value (SECURE_GATEWAY=https://gw.local/edge → weights traffic goes to gw.local/proxy while server traffic goes to gw.local/edge/proxy).

Both wrappers implement the same /proxy?url= contract; they should either share one implementation or be kept behavior-identical with cross-package tests.

2. Per-run step_execution_mode bypasses the env-level hosted-endpoint gate: #2658 forces WORKFLOWS_STEP_EXECUTION_MODE=local behind SECURE_GATEWAY when the hosted target is configured, but a caller passing workflows_core.step_execution_mode=StepExecutionMode.REMOTE via init_parameters still routes all 42 run_remotely blocks at HOSTED_*_URL — unreachable behind a gateway. The durable fix is gateway support in inference_sdk's InferenceHTTPClient (it path-joins onto api_url, which cannot compose with /proxy?url=<encoded>), or a guard at the StepExecutionMode consumption point.

Context: #2658, #2263.

[arthi-arumugam-git]

Opened #2748 for part 1 of this: the idempotence guard and the dropped gateway base path.

Both reproduce exactly as described. On main a second wrap produces
https://gw.local/proxy?url=https%3A%2F%2Fgw.local%2Fproxy%3Furl%3D..., and
SECURE_GATEWAY=https://gw.local/edge does send weights to gw.local/proxy while server
traffic goes to gw.local/edge/proxy.

One thing worth flagging from writing it: the two fixes interact. Once the base path is
preserved, the idempotence guard has to compare against a prefix that includes that path,
or fixing the path reintroduces double-wrapping under /edge. There is a test for that
case on its own.

I went with "behaviour-identical plus cross-package tests" rather than a shared
implementation, since sharing would put a dependency between the two packages. The parity
test sits in the inference unit suite because that workflow already installs
inference_models; happy to move it if you would rather it lived elsewhere.

Part 2, the per-run step_execution_mode bypass, is untouched. That reads like a design
decision about where the guard belongs rather than a divergence between two functions, so
I did not want to pick for you.

[adhavan18]

@alexnorell part 1 landed in #2747, so if nobody is on part 2 (the per-run step_execution_mode bypass) I'd like to take it.

before writing anything, the read i'd work from, in case it's wrong:

the env-level gate from #2658 lives in env.py and only rewrites the default:

elif (
    SECURE_GATEWAY
    and WORKFLOWS_STEP_EXECUTION_MODE == "remote"
    and WORKFLOWS_REMOTE_API_TARGET == "hosted"
):
    ...
    WORKFLOWS_STEP_EXECUTION_MODE = "local"

a caller passing workflows_core.step_execution_mode=StepExecutionMode.REMOTE through init_parameters never reads that value, so the gate can't see them.

of the two options you list, i'd go for the guard at the consumption point rather than gateway support in inference_sdk, because the hook already exists and already does this job for the other flag:

# inference/core/workflows/offline.py
def ensure_workflow_step_execution_mode_allowed(step_execution_mode) -> None:
    if not OFFLINE_MODE:
        return
    ...
    raise WorkflowEnvironmentConfigurationError(...)

called from steps_initialiser.py:140 exactly when that init parameter is consumed. extending it to cover SECURE_GATEWAY + hosted target keeps both bypass rules in one place and matches how env.py already reasons about the pair.

one thing i'd want your call on: env.py warns and falls back to local, but this hook raises. for an explicit per-run override i lean towards raising, since silently downgrading a mode the caller asked for is how you end up debugging why remote execution isn't happening. happy to make it fall back instead if you'd rather the two paths behave identically.

inference_sdk gateway support is the larger fix and i'd leave that out of scope here unless you want them together.