UTS: assert authorize() supersedes stored authOptions (key not preserved)

[owenpearson]

Ruling

Closes #531. Rules in favour of Reading 2 — the key is superseded. Per the plain reading of RSA8e and RSA10j, passing an AuthOptions argument to authorize() supersedes the stored AuthOptions in their entirety (AuthOptions#key included), so a key configured on the constructor is discarded when the argument omits one. This is what both ably-python and ably-js already do, so no features.md change and no SDK change are required.

What the section used to claim vs what it now asserts

The section RSA10i - authorize() preserves key from constructor (rest/unit/RSA10i/authorize-preserves-key-0) asserted, in prose, that the constructor key is preserved across an authOptions argument — a behaviour features.md does not state (features.md:262 RSA10i is merely a pointer into RSA8, not a preservation rule). Its assertions block was three comments with no ASSERT, i.e. silently zero coverage.

It is now retitled RSA10j - authorize() authOptions argument supersedes stored key, with Test ID rest/unit/RSA10j/authorize-supersedes-authoptions-key-0, and asserts the specified superseding behaviour: after authorize(authOptions: AuthOptions(authUrl: ...)) with no key, the constructor key is gone; a further authorize(authOptions: AuthOptions()) — leaving no key, authUrl or authCallback — fails with 40101 / statusCode 401 ("No key specified"), as raised by ably-js in this situation.

Merge order

This branch shares uts/rest/unit/auth/authorize.md with the mock-HTTP PR #534 and the spec-point-references PR #539. Rebase this branch after those merge.

🤖 Generated with Claude Code