Support full-access profile for websocket transport

[Yehonal]

Summary

• allow the plugin to expose a full-access profile when using websocket transport
• keep the existing stdio behavior unchanged

Why

Today buildFullAccessPluginSettings() returns null for any non-stdio transport. That means websocket-backed deployments can never switch a bound thread into Full Access / YOLO mode, even when the remote Codex app-server is intentionally configured for full access.

In our deployment this blocked /cas_status --yolo entirely for websocket mode, despite the remote Codex app-server already running with:

• approval_policy=never
• sandbox_mode=danger-full-access

What this changes

For transport === "websocket", reuse the same plugin settings to create the additional full-access profile instead of returning null.

This is intentionally minimal:

• no change to stdio handling
• no change to defaults
• websocket full-access remains opt-in in practice, because the remote server must still actually be configured to run that way

Notes

This PR only addresses profile availability in the plugin. It does not try to solve unrelated MCP/auth issues in remote environments.

[Yehonal]

@huntharo

[Yehonal]

Superseded by integration/yehonal-cas-stack reconciliation; closing this PR to avoid duplicate history.