railway environment edit --service-config silently no-ops for deploy.* fields (JSON patch form works)

[tfrewmd]

railway environment edit --service-config <svc> deploy.<field> <value> silently no-ops ("No changes to apply") for any deploy.* field, while the equivalent JSON-patch form works correctly

CLI version

Reproduced on both:

• 5.26.0
• 5.43.1 (upgraded specifically to rule out a fixed bug — same result)

Steps to reproduce

1. Have a service with an existing deploy.startCommand set (in my case, a cron-schedule service running a curl command).
2. Run:

   railway environment edit \
     --project <project-id> \
     --environment <environment-id> \
     --service-config <service-name-or-id> deploy.startCommand "some clearly different value" \
     --json
   

3. Observed output:

   {"committed":false,"message":"No changes to apply","staged":false}

   No error, no diff, and railway environment config --json afterward confirms the field was not updated.

What I expected

The dot-path patch should detect that the new value differs from the current one and commit the change (or at least stage it with --stage), matching the documented behavior (railway environment edit --service-config <service> deploy.startCommand "npm start").

Additional testing

• Tried both the service name and the service ID for <service> — same silent no-op both times.
• Tried with and without --stage — same result, no staged diff appears either way.
• Tried a different deploy field (deploy.restartPolicyType, changing "NEVER" → "ON_FAILURE") on the same service — also silently no-op'd. So this isn't specific to startCommand; it looks like the dot-path diffing isn't recognizing changes to deploy.* fields at all for this service.
• The JSON patch form of the same command, targeting the same service by ID, worked correctly on the first try and actually committed + triggered a redeploy:

  railway environment edit --project <project-id> --environment <environment-id> --json <<'JSON'
  {"services":{"<service-id>":{"deploy":{"startCommand":"new value"}}}}
  JSON
  

  Output: {"committed":true, ..., "staged":true}, and railway environment config --json confirmed the field was updated, with a new deployment created automatically.

Impact

This makes the documented dot-path patch syntax for deploy.* fields unreliable — it fails silently with no error, so it's easy to believe a config change went through when it didn't. Took some time to notice since there's no error, just a "no changes" message that reads like a no-op you asked for rather than a bug.

Workaround

Use the JSON-patch form (railway environment edit --json) instead of --service-config for deploy.* fields, with the service targeted by ID.

[anishfyi]

After tracing this on current master, the reported no-op follows the same non-TTY flag-priority path already addressed by open PR #1045 for #1044. I am withdrawing to avoid shipping a duplicate fix.