fix: Disallow subscribing to values of the wrong kind

[jkeiser]

Right now, PUT /attributes lets you subscribe to a value of the wrong kind. Since Claude is doing a lot of PUT /attributes, we need that not to work (because sometimes it makes mistakes, and some of those mistakes can mess up the workspace, including subscribing from a non-secret to a secret.)

array -> string / array -> object subscriptions are disallowed the same way; as such, this PR also removes the long-deprecated automatic si:normalizeToArray function in subscriptions (since now all you can do is array-to-array). There is no way in the UI to subscribe from an array to a single value, so this should not cause problems in the UI. We have left the keepExistingSubscriptions parameter in the API until we're sure clients have transitioned, but it's ignored and is no longer in tests or docs.

Out of Scope:

• We should also check if a secret prop is subscribing to a non-secret, even if they are the same prop kind.
• The UI doesn't check the target prop's type right now, and lets you try to subscribe; you get a silent error if you do it wrong. This isn't much different from before, where the subscription succeeded but the value was either empty or wrong!

How was it tested?

• Integration tests pass
• New integration tests for subscribing to the wrong type
• Manual test: subscribing array -> array, map -> map, object -> object, string -> string, number -> number works
• AI test: When you ask Claude to subscribe to a secret using /resource_value, it gets a reasonable error back and then corrects itself.

In short: 🔗

[github-actions]

Dependency Review

✅ No vulnerabilities or OpenSSF Scorecard issues found.

Scanned Files

None

[britmyerss]

This might be an example where we want to turn the error into a more friendly response that returns from luminork vs. the 500 that it'll probably return now

[jkeiser]

Interesting, will the 500 omit the actual painstakingly crafted error message?