fix(bridges): treat bridge names case-insensitively on read and on create

[ozpool]

Description

Closes #9785.

bridges.ParseBridgeName lower-cases bridge names, and the JSON-API controllers use that parser end-to-end (POST /v2/bridge_types, GET/PATCH/DELETE /v2/bridge_types/:BridgeName). The docs (External adapters) state that bridge names are case-insensitive. Two paths were skipping the parser and breaking that contract:

1. Pipeline runtime — core/services/pipeline/task.bridge.go

getBridgeURLFromName was raw-casting the spec-provided name to bridges.BridgeName and looking it up as-is:

bt, err := t.orm.FindBridge(ctx, bridges.BridgeName(name))

A job spec referencing a mixed-case bridge (e.g. OpenWeatherMap) would therefore fail at run time with could not find bridge with name 'OpenWeatherMap', even though the bridge had been created successfully via the JSON API (which stored it as openweathermap). The user in the linked issue described exactly this symptom.

AssertBridgesExist (core/services/job/orm.go:142) already calls bridges.ParseBridgeName on the same name when validating job creation, so a job referencing OpenWeatherMap validates fine but explodes on first run — strictly worse than failing fast.

2. GraphQL — core/web/resolver/mutation.go

createBridge built the BridgeTypeRequest with a raw cast:

btr := &bridges.BridgeTypeRequest{
    Name: bridges.BridgeName(args.Input.Name),
    ...
}

Bridges created via GraphQL with mixed-case input were therefore persisted with the original case, while every read path (JSON-API show/update/delete, pipeline runtime, etc.) looks them up lower-cased — producing 404s and lookup failures.

Fix

Both call sites now route the name through bridges.ParseBridgeName, which lower-cases and validates the character set. This matches the JSON-API behaviour and the documented contract.

Diff is intentionally tight; the update mutation (mutation.go:481) takes the same shape but is gated behind a separate ParseBridgeName(args.ID) lookup that already normalises, so its raw cast for the new name is benign here. Happy to clean that up in a follow-up if reviewers want it on the same path.

Tests

I don't have a Postgres test database wired up locally, so I couldn't run the DB-backed TestBridgeTask_ErrorIfBridgeMissing (or the broader job/bridge tests) directly. The fix preserves the existing error message shape (could not find bridge with name '<input>') so that test continues to assert the same string. CI will exercise the full suite once a maintainer triggers it.

Local checks I did run:

$ go build ./core/services/pipeline/ ./core/web/resolver/
$ go vet ./core/services/pipeline/ ./core/web/resolver/

Both clean.

Diff

 .changeset/fix-bridge-name-case-insensitive.md | +9
 core/services/pipeline/task.bridge.go          | +10 -1
 core/web/resolver/mutation.go                  | +10 -1