Implicit attach on channel.objects.get() call

[lawrence-forooghian]

As already implemented in JS in ably/ably-js@9bde15.

Split out of #427 since it's a standalone behaviour.

[sacOO7]

Review against ably-js implementation

I've cross-checked this PR against ably-js realtimechannel.ts:1135-1150 (ensureAttached) and realtimeobject.ts:88-101 (get()). The new RTO1e/f line up with the implementation for the four states they enumerate, but there are a couple of gaps worth tightening before merge.

🟠 SUSPENDED state behaviour not addressed

The new RTO1e/f cover INITIALIZED, DETACHED, DETACHING, ATTACHING, and FAILED, but say nothing about SUSPENDED. The implementation's ensureAttached (source) explicitly passes SUSPENDED through without re-attaching:

async ensureAttached(): Promise<void> {
  switch (this.state) {
    case 'attached':
    case 'suspended':
      break;
    case 'initialized':
    case 'detached':
    case 'detaching':
    case 'attaching':
      await this.attach();
      break;
    case 'failed':
    default:
      throw ErrorInfo.fromValues(this.invalidStateError());
  }
}

That's deliberate — a SUSPENDED channel may have local object data that the user can still read while the connection is being re-established. The current RTO1 wording is ambiguous about this case (a reader might assume SUSPENDED falls into "or any other non-attached state" and so gets re-attached, which is wrong).

Suggest adding:

- (RTO1g) If the channel is in the `ATTACHED` or `SUSPENDED` state, proceed without attaching.

…and renumbering / making the relationship between RTO1e/f/g explicit. The simplest framing matches the impl's switch statement:

State	Behaviour
ATTACHED, SUSPENDED	Pass through; do not re-attach.
INITIALIZED, DETACHED, DETACHING, ATTACHING	Implicit attach and wait.
FAILED	Throw ErrorInfo 400/90001.

🟠 Behaviour during pending implicit-attach if the channel transitions to FAILED

RTO1e says "implicitly attach the RealtimeChannel and wait for the attach to complete" but doesn't define what happens if the attach attempt itself fails, or if the channel transitions to FAILED during the wait. The impl simply propagates the attach() rejection (realtimechannel.ts:1144 → standard attach() failure semantics).

Worth being explicit:

- (RTO1e1) If the implicit attach fails (e.g. the channel transitions to `FAILED` during the wait), the returned promise MUST reject with an `ErrorInfo` 400/90001.

🟡 RFC 2119 keyword precision

(RTO1f) says "the library should throw" — should this be MUST? The pre-existing (RTO1b) used the same "should" wording, but per CLAUDE.md's writing principles ("Use RFC 2119 keywords precisely"), throwing for a FAILED channel is a hard requirement. Suggest "MUST throw".

⚪ Minor: cross-reference to RTL27 lifecycle

For readers landing on this clause without context, a one-line cross-reference to channel-state transitions (RTL2) and the implicit-attach pattern used elsewhere (e.g. RTP11b for presence.get(), mentioned in the PR description) would help with consistency framing.

---

These observations correspond to issue B-3 in LIVEOBJECTS_SPEC_REVIEW.md (cross-branch review) and Task B-6 in LIVEOBJECTS_UPDATE_SPEC_ACTIONABLE_PLAN.md.

[sacOO7]

LGTM.
Addressed changes as per review comment and now behaviour is exactly similar to JS code.

[lawrence-forooghian]

This is a behavioural change compared to RTP11b i.e. a DETACHED channel now gets implicit attach, instead of throwing an error. Our docstrings aren't specific about the circumstances in which an implicit attach gets performed so I think we can get away with it, and I don't see any obvious reason why we wouldn't want to do it, but I thought it worth pointing out.

[sacOO7]

This behaviour follows current ably-js implementation -> #472 (comment)

[sacOO7]

c5627f8

[lawrence-forooghian]

This behaviour follows current ably-js implementation

Sure, I get that; I'm saying that the ably-js implementation is different to the spec and it's not obvious that the ably-js behaviour is the one that we want (but that it's minor)

[lawrence-forooghian]

LGTM, I can't approve because it's my PR, but approved