[FEATURE] Introduce ContextVar-based session metadata access (e.g., client_id)

[BloggerBust]

Is your feature request related to a problem? Please describe.

While implementing WebSocket-powered Fastplotlib components, we needed a way to route image updates to the correct frontend client. This required accessing the client_id from within the user's script (e.g., hello.py) and passing it through to the backend component.

To support this in the short term, we introduced a workaround: importing the internal PreswaldService directly and calling get_component_state("client_id"), then manually attaching the client_id to the figure object (e.g., fig._client_id = client_id) before passing it to fastplotlib().

While functional, this approach breaks abstraction by exposing internal service APIs to user scripts, introduces implementation leakage, and increases the burden on users of the component. This issue proposes a more robust and production-ready solution to cleanly manage session-level metadata like client_id.

---

Describe the solution you'd like

Introduce a session context management system that automatically injects session metadata (e.g., client_id) into the runtime of user scripts. This could be implemented using a ContextVar set during ScriptRunner initialization.

Expose a lightweight public API for accessing session metadata:

from preswald import session
client_id = session.get("client_id")

Internally, components like fastplotlib() can fetch the client_id from this context, removing the need for users to manually retrieve and pass session data. This keeps user code clean, declarative, and free from internal service imports.

---

Describe alternatives you've considered

• The current workaround, which involves calling PreswaldService.get_component_state("client_id") and manually setting it on the figure (e.g., fig._client_id = client_id). This approach works but exposes internal APIs and burdens the user with unnecessary boilerplate.

• Implementing a full backend session service, where each WebSocket connection is tracked as a formal session object, and components can query session state via a dedicated API. While more extensible (e.g. for authentication, persistence, or user preferences), this would introduce significantly more complexity. At this stage, the ContextVar approach gives us most of the same benefits with much lower overhead and is more aligned with how Preswald scripts are executed today.

---

Additional context

This change would:

• Improve the developer experience
• Maintain proper encapsulation of session internals
• Eliminate the need to import PreswaldService in user scripts
• Prevent errors related to missing or incorrectly attached client_ids
• Reinforce Preswald’s declarative programming model

It would also make future session-based features (e.g., authentication, per-user preferences, etc.) easier to implement in a consistent way.

Note: A ContextVar-based solution is ideal for single-process, local, or small-scale deployments. However, it does not persist across multiple backend processes or distributed environments (e.g., containerized setups behind a load balancer). When we are ready to scale, a more robust backend session service (e.g., backed by Redis or a shared DB) will be required to reliably manage session state across workers.