Phase 5: evaluate transparent object proxying (stretch)

[zacharywhitley]

Background

Design: docs/native-execution-and-parallelism.md §4 (rationale), §9 step 5.
Depends on #4.

Only pursue if call-with-serializable-args (Phases 1/4) proves insufficient.

Tasks

• Assess concrete cases where call-offload is inadequate (live ndarray views,
  callbacks crossing the boundary, stateful objects, __getattr__ chains).
• If justified, prototype transparent cross-boundary object proxying and
  document the cost/complexity trade-offs.

Notes

Research-grade; explicitly out of scope for v1. This issue exists to capture the
decision point, not to commit to building it.

[zacharywhitley]

Assessment complete (docs/tier5-transparent-proxying.md, 82fdd2c)

Evaluated whether call-with-serializable-args (Phases 1/4) is sufficient.

Where v1 breaks down: live object handles/identity, stateful objects + method
calls, mutation of results, callbacks/higher-order calls (need backend→host calls
mid-request), iterators/generators/context managers, non-serializable args/returns.

What transparency would cost: effectively a distributed-objects layer (the
RPyC/Pyro problem) — remote handles + GC, the whole Python data model over the
wire, a bidirectional channel, and a stateful session pinned to one worker that
conflicts with the shared-nothing fan-out that makes Tier P parallel.

Recommendation / decision — defer. Keep v1 call-offload as the contract. If
stateful use cases appear, add a minimal explicit handle API
(create / call_method / release) rather than general transparency; support
callbacks only once a bidirectional channel (girder host.call) exists; consider
RPyC only if full transparency is ever truly required.

Leaving this issue open as the record of that trigger condition (revisit if/when
concrete stateful or callback use cases show up).