v0.2.8 - Changelog

Highlights

Made Provider1 failed-task refunds task-level idempotent. Status polling, webhook failure handling, and generate-time rollbacks now share one refund key (provider1:failure-refund:<task_id>), so concurrent status + webhook paths cannot double-credit users.
Node1 /internal/credits/add now treats source_id as a real idempotency key (D1 migration 0027): same key + same amount replays as success; same key + different amount returns 409.
When a duplicate failure refund is intercepted, Provider1 records a warning and notifies the site owner through configured Notify channels (Bark / Feishu / DingTalk, etc.).
Added guest credit risk controls in Node1 (migration 0026) so operators can limit abuse of guest demo credits more safely from admin.

Failed AI tasks refund credits once per task, even under concurrent webhook and status updates — balances stay accurate.
Site owners get an alert when a duplicate refund attempt is blocked, instead of silent double-spend of credits.
Guest demo credit abuse is easier to constrain without turning guest login off entirely.

Deploy order for this release: apply Node1 migrations 0026 + 0027, deploy zship-node1-auth, then deploy zship-provider1.
Covers ZA-650 (refund idempotency + alerts) and ZA-649 (guest risk controls) shipped together on Node1/Provider1.