fix(link): revoke endpoint was disabled by its own rate-limit rule

Live QA: every call to /v1/devices/revoke returned 429 retry_after=3600.
The rule was written (0, 3600) with a comment saying 'never throttle someone
out of signing a lost laptop out' -- but in this limiter a limit of 0
DISABLES the endpoint outright. The comment said unlimited; the code said
never. Set to 600/hour instead.

Every unit test passed while the endpoint was 100% dead over HTTP, because
they called svc.revoke_device() directly and never went through the handler.
Added 4 tests that speak HTTP, including one that fails if ANY route in
DEFAULT_RATE_RULES is configured to 0.

176 tests (was 172).

server/granthi_link.py

@@ -90,9 +90,14 @@ DEFAULT_RATE_RULES = {"/v1/link": (5, 3600), "/v1/repos": (60, 3600),
                       # Reads are cheap but still authenticated work.
                       "/v1/devices": (120, 3600),
                       "/v1/audit": (120, 3600),
-                      # Revocation is a safety action: never throttle
-                      # someone out of signing a lost laptop out.
-                      "/v1/devices/revoke": (0, 3600)}
+                      # Revocation is a safety action, so its limit is set
+                      # high rather than tight. It is NOT 0: in this limiter
+                      # a limit of 0 DISABLES the endpoint outright (see
+                      # RateLimiter.check), which would mean nobody could
+                      # ever sign a lost laptop out. Caught in live QA --
+                      # unit tests called the service method directly and so
+                      # never went through the limiter at all.
+                      "/v1/devices/revoke": (600, 3600)}
 MAX_RATE_KEYS = 10000