Finish provider reuse investigation and measured adoption decision #363

Description

Investigate provider-instance reuse and decide when applications should opt into retaining expensive immutable state. The transferred context in trusted-server#856 asks for a measured go/no-go spike covering SDK/runtime support, isolation and config/signing-key rotation.

Much of the framework work is already delivered by PR #379: Fastly retained/custom serving helpers, Cloudflare/Spin caller-owned dispatch, lifecycle guidance and local provider fixtures. implemented reusable-lifecycle design and evidence boundary explicitly limits its evidence to host/local behavior and leaves deployed lifetimes and application performance unverified. Keep this issue focused on the remaining investigation rather than recreating those APIs.

Steps to reproduce

Inspection steps (no runtime experiment executed):

1. Read implemented reusable-lifecycle design and evidence boundary and custom lifecycle implementation and remaining evidence limits.
2. Review the implemented provider fixtures and their successful, unsupported and unverified results in PR #379.
3. Compare them with the transferred spike’s config/key-rotation, comparative measurement and go/no-go criteria.

Expected behavior

A revision-pinned provider/workload report explains supported reuse, safe retained versus request-owned state, rotation policy, rollback and the measured adoption decision. Unavailable measurements or host behavior are reported as blockers/limits rather than assumed guarantees.

Impact

Reuse can reduce repeated parsing/construction, but stale configuration, keys, privacy state or unbounded caches can cross requests. Implemented framework APIs alone do not establish a performance benefit for a consuming workload.

Proposed fix

Reuse the existing opt-in lifecycle fixtures and document what main already proves. Complete the remaining provider/runtime and target-workload experiments at explicit request limits, preserving a one-request/default rollback. Inventory retained state and exercise distinct fictional identities/consent plus config/key changes where supported. Measure initialization, cold/warm and tail latency, throughput, memory growth and error rate under comparable workloads; document blockers and a go/no-go decision without changing defaults.

Done when

• Document current pinned SDK and target-runtime reuse availability and constraints.
• Record the existing opt-in multi-request prototype and explicit rollback path; exercise any remaining target-runtime gaps.
• Cover cross-request isolation and config/key rotation, with explicit documented blockers where the runtime cannot support a case.
• Attach comparable before/after initialization, latency/tail, throughput, memory and error measurements with workload and revision details.
• Record a provider/workload go/no-go decision and keep deployment defaults unchanged until justified.
• Separate local evidence from deployed eviction/lifetime/resource validity and performance guarantees.

Related

PR #379 is a partial implemented foundation; implemented reusable-lifecycle design and evidence boundary; trusted-server#856 and its handoff comment.