fix(subscriptions): rebuild subscriber when getConfig() subscribe changes

[jimmy-phantom]

Summary

Fixes a bug where getConfig() returning a different subscribe value mid-session had no effect: setupSubscription only consulted config.subscribe at activation, on params change, or when no subscriber was running, so once a subscriber was active any later value produced by getConfig() was ignored.

The two patterns that motivated the fix:

// Adapt poll interval to response state
getConfig() {
  return { subscribe: poll({ interval: this.response?.ok ? 100 : 5000 }) };
}

// Stop polling on a terminal error
getConfig() {
  return {
    subscribe: this.response?.status === 404 ? undefined : poll({ interval: 5000 }),
  };
}

These are the canonical legitimate getConfig() use cases: config field values that genuinely depend on per-fetch runtime state.

Approach

One rule: subscribe rebuilds when its reference changes from what's currently installed. No marker, no opt-in mechanism, no asymmetry between user code and built-in factories.

• setupSubscription tracks lastSubscribeFn and short-circuits on ref equality. The post-fetch path always invokes it. The previous unsubscribe === undefined guard skipped the case where the new value is undefined and a running subscriber should be torn down.
• runQuery re-resolves options after the fetch resolves so getConfig() observes the freshly assigned this.response before setupSubscription runs.
• Param-change rebuilds clear lastSubscribeFn before calling setupSubscription, since the running subscriber captured the old params.

Trade-off worth flagging

Any subscribe value placed inside getConfig() produces a fresh function reference each call (whether it's poll(...) or an inline closure). The framework treats this honestly: re-evaluating getConfig() on each fetch produces a new ref, so the running subscriber is torn down and rebuilt. Per-fetch cost is one closure allocation, one cleanup call, and one clearTimeout/setTimeout swap for poll-like subscribers. Timing is unaffected because the next tick is scheduled interval ms after fetch resolution either way.

The escape hatch for stable subscribers is static config = { subscribe(...) { ... } }, which evaluates once at class-field-init time and gives a stable ref. The two forms have clear, distinct, predictable semantics:

• config = ... for stable subscribers (the common case).
• getConfig() when the value of a config field genuinely depends on runtime state.

Earlier iterations of this PR experimented with a marker-based opt-in mechanism (SUBSCRIBE_KEY) and a pollCache to give built-in factories stable identity. Both were removed in favor of the simpler rule above. The marker created a hidden distinction between built-in and user code that users would have to learn; the cache was an asymmetric optimization that only benefited poll() while leaving inline closures churning.

Test plan

• Two failing repros (honors a state-dependent interval after first fetch resolves, stops polling when getConfig() switches subscribe to undefined after an error) now pass
• Three lifecycle tests in query-stream.test.ts converted to static config = ... (their config values never depended on runtime state)
• Full unit suite: 1135 passed
• Full React suite: 94 passed
• tsc --noEmit clean

🤖 Generated with Claude Code

[jimmy-phantom]

Closing in favor of #25