d360_transform_update uses PATCH but data transform update endpoint allows PUT, not PATCH

## Summary

`d360_transform_update` currently calls `PATCH /ssot/data-transforms/{id}` and the family catalog also describes the update operation as `PATCH`. In a Data 360 org on API version `66.0`, that endpoint rejected PATCH and reported that PUT is the allowed update method.

## Observed behavior

Calling the MCP facade workflow:

1. `search` for data transform update tools
2. `payload_examples` for `d360_transform_update`
3. `execute` with `toolName: "d360_transform_update"`

returned this API error:

```json
{
"error": "Data 360 API error 405 on /ssot/data-transforms/1dt...: [{\"errorCode\":\"METHOD_NOT_ALLOWED\",\"message\":\"HTTP Method 'PATCH' not allowed. Allowed are DELETE,GET,HEAD,PUT\"}]",
"statusCode": 405,
"path": "/ssot/data-transforms/1dt..."
}
```

## Current implementation

At commit `fc7ad1f9c1e01f41f93ec2588419d52ac45ad41b`:

- `DataTransformTools.updateDataTransform(...)` calls `client.patch(...)`
- `FamilyCatalog` registers `d360_transform_update` as method `PATCH` for `/ssot/data-transforms/{id}`

## Expected behavior

`d360_transform_update` should use the HTTP method accepted by the Data 360 API for editing an existing data transform. Based on the live API response above, this appears to be `PUT`, not `PATCH`.

A compatible fix could be:

- change `d360_transform_update` and the catalog metadata from PATCH to PUT

## Additional note

After locally switching the method to PUT for testing, the update reached normal request validation instead of failing at method validation. The PUT request required the transform-level `type` field in the editable request envelope, so the payload requirements may also differ from a PATCH-style partial update.

Start by reading DataTransformTools.updateDataTransform(...) and the FamilyCatalog entry for d360_transform_update. Verify the PUT behavior against the Data 360 API, including the required transform-level type field, then confirm that the tool and catalog use PUT and that a valid update reaches normal request validation without the 405 error.

Written by the indexing model from the issue text.