badge service: do not treat a Play token the service will not send as Play's refusal

docs/protocol/badges-rpc.md

@@ -36,7 +36,7 @@ No command lets the client state what is signed. The tier is that of whatever fu
   - A store verifier's answer falls in one of three classes, and the class decides what happens to a paid purchase. On `receipt_invalid` the client deletes the keys it signed with and finishes the store transaction — consumed on Play, finished on StoreKit — so a purchase answered `receipt_invalid` by mistake is lost to its buyer for good: the money has moved and nothing can present the transaction again. The opposite mistake costs one request at each of the client's own triggers, and Play refunds a purchase that is not acknowledged within three days. An answer that is not certainly in the first class is in the third.
     - Terminal, `receipt_invalid`: the store has answered about this purchase, and the answer cannot change — an Apple signature that does not verify, a chain that does not lead to Apple's root, another app's bundle id, a test purchase (Apple's Sandbox, Play's `purchaseType` test), a revoked or refunded purchase, Play's `purchaseState` canceled.
     - Pending, `payment_pending`: the store knows the purchase and it is not complete — Play's `purchaseState` pending.
-    - Unreachable, `provider_unavailable`: the store was not asked or has not answered about the purchase — network failures, timeouts, 5xx, quota, this service's own authentication or permission failures, and a 404 when reading the purchase (`purchases.products.get`, `purchases.subscriptionsv2.get`). Play may not yet know a token it has just issued, and no answer tells that apart from a token it never issued. Play is asked under this app's package name, so another app's token is treated the same way, and so is every other Play error response, a 400 or 410 that calls the token invalid included: only a purchase record Play returns is a verdict. A Play product id or token outside the characters Play issues is refused as `receipt_invalid` before Play is asked, so that alphabet must be the one Play documents, not a guess.
+    - Unreachable, `provider_unavailable`: the store was not asked or has not answered about the purchase — network failures, timeouts, 5xx, quota, this service's own authentication or permission failures, and a 404 when reading the purchase (`purchases.products.get`, `purchases.subscriptionsv2.get`). Play may not yet know a token it has just issued, and no answer tells that apart from a token it never issued. Play is asked under this app's package name, so another app's token is treated the same way, and so is every other Play error response, a 400 or 410 that calls the token invalid included: only a purchase record Play returns is a verdict. A token outside the characters this service will put in a request to Play is not sent, and is answered in this class too: Play documents no grammar for a token, so the service's check is not Play's verdict. A product id outside the characters Play documents for one is `receipt_invalid`, since no product of this app can have it.
     - Apple is verified offline, so it has no "not yet": a negative answer about the signed evidence itself is terminal. A failure of the verifier's own, such as a root certificate it could not load, is not Apple's answer: it is answered `internal`, on which the client keeps the purchase. Google is asked, so its silence and its 404 are not verdicts.
     - A product this service does not price is not the store's refusal: the verifier vouches for the transaction, and the service answers `product_unavailable`, on which the client keeps the purchase.
   - Funding by `receipt` is a transfer (post-MVP): the unissued months of the purchase that receipt belongs to move to the signing key, recorded as `debit(transferOut)` on the source and `credit(transferIn)` on the new purchase, and the presented receipt is retired for a fresh one. The transferred period's issuance debits a month like any other. Lifetime badges hold no receipt, so support handles them.