fix(gateways): strip trailing /v1 from OPENAI_API_BASE in bifrost/start

[cdoron]

bifrost's openai/anthropic provider clients append their own /v1/...
suffix to network_config.base_url. This repo's convention (matching the
OpenAI SDK) is that OPENAI_API_BASE already includes a trailing /v1, so
substituting it unmodified into bifrost's config produced a doubled path
(/v1/v1/chat/completions) that 404'd on every request. Strip the trailing
/v1 before substitution, mirroring litellm/start's identical
normalization.

Signed-off-by: Doron Chen cdoron@il.ibm.com

[elronbandel]

Fix strips `/v1` uniformly from `OPENAI_API_BASE` for both the anthropic and openai provider blocks, on the premise that bifrost's openai client double-appends `/v1` just like its anthropic client does.

But `litellm/start`'s own comment (a few lines above, same repo) says these two behave asymmetrically there: anthropic auto-appends `/v1/messages` (needs the bare root), while openai uses `OPENAI_API_BASE` as-is, already including `/v1` (no auto-append). If bifrost mirrors that same asymmetry rather than being uniform, openai is already working correctly today (base already has `/v1`, final path resolves right) — and this fix would strip the `/v1` it needs, trading a real anthropic 404 for a new openai one.

Nothing in the test suite disambiguates this either way: the existing assertions (`fwd_path.contains("chat/completions")`) are substring checks that pass whether the real forwarded path is `/chat/completions` or `/v1/v1/chat/completions`.

Please confirm bifrost's actual openai-vs-anthropic base_url handling (source read or a live/mocked request asserting the exact path, not a substring) before we merge — ideally split the openai and anthropic normalization so we're not assuming they're identical.