Server-side scenario execution: thin effects client replaces local engine

- engine/ (DagWalker, sessions, IndexedDbPlanStore) deleted; server owns the graph
- trigger/callback/counter carry PendingEffect; GET /sdk/v1/scenarios/pending polled
  (30s jittered heartbeat paused on hidden tab + wait-deadline timers)
- client.effects public API unchanged (done/buy/dismiss/end/claim/battlepass/quest)
- planStateStore removed; loginEvent kept; reconcile() makes server the source of truth
- generated models regenerated; skills/README/CHANGELOG updated

skills/rudder-web-sdk/reference/battlepass.md

@@ -34,7 +34,6 @@ interface AddBattlePassXpResponse {
   level?: number;
   leveledUp?: boolean;
   maxLevel?: boolean;
-  plan?: ExecutionPlan;  // scenario plan continuation, handled by the runtime
   xp?: number;
 }
 
@@ -67,7 +66,6 @@ interface PurchaseBattlePassPremiumRequest {
 }
 interface PurchaseBattlePassPremiumResponse {
   error?: string;
-  plan?: ExecutionPlan;
   success?: boolean;
 }
 ```
@@ -82,6 +80,5 @@ interface PurchaseBattlePassPremiumResponse {
   in the response and the typed error `code` (`RudderErrorCodes`).
 - `purchasePremium` charges the player's wallet; idempotent; pass your own
   `idempotencyKey` for safe retries.
-- Mutations return `ExecutionPlan` continuations — when driving battle pass
-  manually you are responsible for the scenario run state; prefer the
-  `onBattlePass` effect session which handles this.
+- Prefer the `onBattlePass` effect session, which binds `scenarioId` /
+  `nodeId` / `runId` and posts scenario callbacks for you.