Invite tokens: multi-use / expiring support (deferred)

**Deferred design decision — flagged so it is not lost.** The server's invite admission policy ships with **single-use** opaque tokens only (a deployment-issued file of `sha256(token)` hashes; each token admits exactly one new principal and is then marked spent). This was a deliberate scoping choice: single-use is the minimal correct core.

Two extensions were considered and explicitly deferred, not rejected:

1. **Multi-use tokens** — one token that admits up to N new principals (e.g. a shared invite link for an organization onboarding several principals).
2. **Expiring tokens** — a token valid only until a configured time.

The current file+hash token design was chosen specifically because both extensions fit it **without any wire-format change**: the token stays an opaque `X-Cyphr-Invite` header string; only the server-side token record gains a remaining-uses count and/or an expiry timestamp. So nothing about shipping single-use forecloses these.

Revisit when a real deployment need appears (org onboarding, time-boxed invitations). At that point decide: multi-use, expiring, both, and the default. Until then single-use stands.

This issue records deferred support for multi-use and expiring invite tokens; no implementation file or test is named. When a real deployment need appears, first read the current server-side file-and-hash token implementation and decide which extension, defaults, and combined behavior are required. Done means an agreed design and corresponding implementation scope, rather than work on the current single-use behavior.

Written by the indexing model from the issue text.