V1 TaxJar connector disable fails with invalid connector_name

[muditbhutani]

Bug

Disabling a V1 Tax Processor connector, specifically TaxJar, fails from the dashboard with an IR_07 validation error.

Observed behavior

On the Tax Processor > Tax Jar connector details page, clicking the Disable toggle/button sends the connector update request, but the request fails.

Response body observed in browser DevTools:

{
  "error": {
    "type": "invalid_request",
    "message": "Invalid value provided: connector_name",
    "code": "IR_07"
  }
}

The request was made for a TaxJar merchant connector account, with a connector account id like:

mca_uHC9DjybpuHJLmDloxyvn

Expected behavior

The connector should be disabled successfully. Tax Processor connectors should not fail disable/update just because they are not routable payment connectors.

Reproduction

1. Open the V1 dashboard.
2. Go to Tax Processor.
3. Open an existing Tax Jar connector.
4. Click Disable.
5. Confirm the action.
6. The update request fails with IR_07 / Invalid value provided: connector_name.

Investigation notes

The frontend V1 TaxJar page uses TaxProcessorHome.res and sends the disable update through:

ConnectorUtils.getDisableConnectorPayload(
  connectorInfo.connector_type->ConnectorUtils.connectorTypeTypedValueToStringMapper,
  currentIsDisabled,
)

and calls the V1 connector update endpoint:

getURL(~entityName=V1(CONNECTOR), ~methodType=Post, ~id=Some(mcaId))

The payload is only toggling the disabled state and includes the connector type. The failing validation appears to happen after the MCA update path begins on the backend.

In crates/router/src/core/admin.rs, the V1 update_connector flow updates the MCA and then tries to update/default fallback routing config. That path eagerly parses mca.connector_name as euclid::enums::RoutableConnectors:

euclid::enums::RoutableConnectors::from_str(&mca.connector_name).map_err(|_| {
    errors::ApiErrorResponse::InvalidDataValue {
        field_name: "connector_name",
    }
})?

TaxJar is a tax processor, not a routable payment connector. So disabling TaxJar can fail during this fallback-routing cleanup step even though the connector update itself is valid.

Suggested direction

For V1 connector update/delete routing cleanup, non-routable connector types such as tax processors should skip default fallback routing mutation instead of returning InvalidDataValue { field_name: "connector_name" }.

The existing routing helper already accepts Option<RoutableConnectors> and no-ops when the connector is not routable, so the update path likely needs to avoid eager ? parsing for non-routable connectors.