Description

The update commands for synthetic checks, check rules, and views force-set the origin field to "dash0-cli" before sending the update request.
When the asset was originally created with a different origin (e.g., via the Kubernetes operator or the UI), the API rejects the request with a 400 error:

Bad Request: The submitted synthetic check origin does not match the synthetic origin in the request.

Affected commands

• synthetic-checks update — internal/syntheticchecks/update.go:68-69 sets Dash0Comorigin = "dash0-cli"
• views update — internal/views/update.go:68-69 sets Dash0Comorigin = "dash0-cli"
• check-rules update — internal/checkrules/update.go:69 sets labels["dash0.com/origin"] = "dash0-cli"

The same bug existed in dashboards update (overwriting dash0Extensions.id with the origin string) and was fixed in #77.

Expected behavior

The update commands should not modify the origin field.
The API manages origin server-side; the Import* functions in internal/asset/ already strip it before calling the import API.

Actual behavior

The origin is force-set to "dash0-cli", which conflicts with the existing origin on the server and causes 400 errors for assets not originally created by the CLI.

Suggested fix

Remove the origin-setting blocks from all three update commands, matching the fix applied to dashboards in #77.