fix(container-runtime): Give container extensions access to true connected state

[WillieHabi]

Description

This change adds a public getter to ContainerRuntime connectedToService which returns whether or not the client is connected to the service (from ContainerContext). This getter is then passed to the container ExtensionHost runtime so container extensions have access to true connected state.

This is in contrast to the get connected() getter which returns whether or not the client has the ability to send ops (i.e. connected to service and not readonly mode).

[Copilot]

Pull Request Overview

Adds a new public API to expose the service connection status separately from the existing connected getter. Container extensions will now receive the true connected state via the extension host runtime.

• Introduce private _getConnected function and public connectedToService getter
• Initialize _getConnected from context.connected in the constructor
• Update extension host’s isConnected callback to use connectedToService

Comments suppressed due to low confidence (2)

packages/runtime/container-runtime/src/containerRuntime.ts:1196

• The doc comment could clarify how connectedToService differs from the existing connected getter (which also accounts for readonly mode). Consider adding a remark to explain the distinction.

public get connectedToService(): boolean {

packages/runtime/container-runtime/src/containerRuntime.ts:1196

• This new public getter should have accompanying unit tests to verify it correctly reflects context.connected and that the extension host’s isConnected callback behaves as expected.

public get connectedToService(): boolean {

[markfields]

Change makes sense, I left some suggestions, ping me when ready for final approval.

[jason-ha]

I think that there is an event that corresponds. If we just change extension isConnected, then those will be uncoordinated. Let's get a coordinated event too.

[jason-ha]

I think it checks more than read-only mode. Something somewhere also checks if incoming op stream has been processed.
We should call out that there is a difference. Perhaps, though, just link or see also to connected and let it speak for itself. (In a public API we'd put these additional comments under @remarks but I don't know what difference it makes for internal docs.)

[WillieHabi]

I think it checks more than read-only mode. Something somewhere also checks if incoming op stream has been processed.

Hmm I haven't seen this before -- looking at the connected() it just returns canSendOps() which is essentially just the lie that container tells containerRuntime in setConnectionState (connected && !readonly). I can just link connected for now and say there's a difference.

cc: @markfields @kian-thompson, do you guys know about additional checks for connected()?

[jason-ha]

This doesn't seem like the correct timing for these events. There is not a strong association between this.isConnected() changing state and being here. Maybe it is correct, but, if so, it requires lots of comments.

I think we like to name events as actions. Perhaps serviceConnected or connectedToService style naming?

[jason-ha]

Also - should add tests for the changes to be even more confident we are getting this right

[WillieHabi]

I added some comments, tests for the new eventing, and the name change