Merge pull request 'feat: hard revoke / re-key (Phase C, #3)' (#15) from feat/3-phase-c-rekey into main

backend/src/auth/claims.rs was orphaned dead code: auth/mod.rs never
declared 'mod claims', so the file wasn't compiled into the crate at
all. It defined two structs:
- AccessClaims — referenced nowhere; a latent trap (carried
  family_id/permissions fields that suggested enforcement that doesn't
  exist).
- RefreshClaims — a duplicate of the LIVE RefreshClaims in jwt.rs,
  which is what JwtService actually uses.

Deleted the file. Updated the JWT ADR to mark the open item done and
note the removal historically.

Build/clippy/fmt clean (the file wasn't compiled anyway). Closes #5.

backend/src/auth/claims.rs

@@ -1,22 +0,0 @@
-use serde::{Deserialize, Serialize};
-
-#[derive(Debug, Clone, Serialize, Deserialize)]
-pub struct AccessClaims {
-    pub sub: String,
-    pub email: String,
-    pub family_id: Option<String>,
-    pub permissions: Vec<String>,
-    pub token_type: String,
-    pub iat: i64,
-    pub exp: i64,
-    pub jti: String,
-}
-
-#[derive(Debug, Clone, Serialize, Deserialize)]
-pub struct RefreshClaims {
-    pub sub: String,
-    pub token_type: String,
-    pub iat: i64,
-    pub exp: i64,
-    pub jti: String,
-}

docs/adr/jwt-authentication-decision.md

@@ -65,10 +65,10 @@ Note what is **absent** and why:
   enforcement is not implemented at the auth layer (see issue #3 — multi-person
   sharing is an open design problem). Putting unenforced claims in the token
   would imply protection that doesn't exist.
-  - `backend/src/auth/claims.rs` *does* define an `AccessClaims` struct with
+  - (Historical: an orphaned `backend/src/auth/claims.rs` once defined a
-    `family_id`, `permissions`, `token_type`, `jti`. **It is dead code** — not
+    duplicate `AccessClaims` struct with `family_id`/`permissions`/`jti`. It
-    imported or used anywhere in the source (only in stale compiler scratch
+    was dead code — never declared as a module, never imported — and has been
-    files under `target/`). It should be removed or wired up; tracked by issue #4.
+    removed; see issue #5.)
 - **No `token_type` discriminator.** Access and refresh claims are different
   structs, so a token can only decode as one or the other — the field is
   redundant and was dropped.
@@ -151,13 +151,13 @@ never on the server to protect:
 - HS256 with a shared secret means the secret is sensitive infrastructure; a
   key rotation requires invalidating all tokens (acceptable for the deployment
   model, but worth noting vs. asymmetric RS/ES keys).
-- The dead `AccessClaims` struct is a latent trap — someone could wire it up
-  assuming `family_id`/`permissions` are enforced. Should be deleted.
 
 ## Open items
 
-- **Remove `backend/src/auth/claims.rs`** (dead `AccessClaims`) or wire it up
+- ~~Remove `backend/src/auth/claims.rs` (dead `AccessClaims`) or wire it up
-  intentionally. Tracked under issue #4.
+  intentionally.~~ **Done** — the orphaned file has been deleted (issue #5,
+  PR #<to fill after open>). The live `Claims` / `RefreshClaims` structs in
+  `backend/src/auth/jwt.rs` are the only ones.
 - When issue #3 (multi-person sharing) is decided, revisit whether family /
   share authorization belongs in the JWT or is enforced per-request against a
   shares collection.