docs(cryptify): document /status endpoint, recovery_token, structured 404, session_ttl_secs

[dobby-coder]

The cryptify reference page (docs/repos/cryptify.md) is missing several recently-shipped upload-protocol features. All of these are merged on main and documented in api-description.yaml.

What needs documenting

1. New GET /fileupload/{uuid}/status endpoint (cryptify#148)

Add to the endpoint list under "API". The route returns (uploaded, cryptify_token, prev_token, prev_offset) and is used by clients to rehydrate an upload across browser refresh / tab crash. Auth is via the X-Recovery-Token header (deliberately separate from the API-key Bearer channel).

• Missing/blank header → 401
• Wrong token value → 404 with the same upload_session_not_found body as a real unknown UUID (info-hiding)
• Successful call also touches the idle-eviction deadline

Source PR: encryption4all/cryptify#148

2. recovery_token field on the POST /fileupload/init response (cryptify#148)

The init response now includes a hex-encoded 32-byte recovery_token. Clients must store it (e.g. IndexedDB) alongside the UUID and replay it on /status. Add it to the init response description on the cryptify page.

3. Structured 404 body for missing upload sessions (cryptify#144)

PUT /fileupload/{uuid} and POST /fileupload/finalize/{uuid} now return a JSON body on 404:

{ "error": "upload_session_not_found", "uuid": "...", "reason": "expired_or_unknown" | "invalid_uuid" | "file_missing" }

The status code is unchanged (still 404), so older clients see the same wire behaviour. Worth a short subsection under "API" so direct API callers know the contract.

Source PR: encryption4all/cryptify#144

4. session_ttl_secs config option (cryptify#144)

The 60-min idle TTL from cryptify#132 is now configurable via CryptifyConfig::session_ttl_secs (default 3600). Add a row to the config table (currently only lists chunk_size).

5. Idempotent chunk-retry protocol (cryptify#145)

Server-side detection of duplicate chunk PUTs: when the client resends with the cached (prev_token, prev_uploaded) and the body SHA-256 matches, the server replays the cached response_token instead of advancing the chain. Mention this under the chunk-PUT description so direct API callers understand the retry contract.

Source PR: encryption4all/cryptify#145

Where to write it

docs/repos/cryptify.md — extend the existing "API" section and the config table. Keep it short and reference the OpenAPI file (api-description.yaml) for full schemas. Verify the build with npm run docs:build.

Source-link convention

Pin code/spec snippets to a full commit hash on cryptify's main (see repos/postguard-docs/notes style rules). Confirm each link returns HTTP 200 before merging.

[dobby-coder]

/dobby

[dobby-coder]

Dobby has heard the call! Dobby is reading the issue, cloning postguard-docs, and will draft the cryptify reference page updates with proper source links. Dobby will report back with a draft PR!

[dobby-coder]

Draft PR up: #69

Covers all five items from the issue:

• session_ttl_secs row in the config table (cryptify#144).
• recovery_token field on the init response (cryptify#148).
• GET /fileupload/{uuid}/status endpoint with auth, info-hiding 404, and idle-deadline reset (cryptify#148).
• Structured upload_session_not_found 404 body shared by chunk PUT, finalize, and status (cryptify#144).
• Idempotent chunk-retry contract, including the link to prev_token/prev_offset on /status (cryptify#145).

All snippet links pin to cryptify 4c30e53 on main and were verified HTTP 200. npm run docs:build passes locally. Left as draft for review.