fix(vault): declare the back-up URL the snapshot store writes

[LKSNDRTMLKV]

Closes #225.

The snapshot store writes {dppId}/public.json. publish declared the registry back-up at {dppId}.json, and .env.example documented that second shape — so the code and its documentation agreed with each other and disagreed with the only thing that actually writes an object. An operator who set SNAPSHOT_PUBLIC_BASE_URL declared a link that fetches nothing.

Why nothing caught it

RegistrationRequest::validate checks the scheme and stops. Its own comment names this outcome —

A back-up the registry cannot fetch is worse than none declared.

— and the check cannot see it, because https://backup.example.com/dpp/{id}.json is a perfectly well-formed HTTPS URL that happens to address nothing. Reachability is the registry's check, so the first party to notice would have been the registry, on a live registration. No test covered the relationship either: the registry suite only ever exercised backup_url: None, which is the default and the only path there was.

The fix, and the part that keeps it fixed

snapshot_json_key moves to dpp-types — the crate both dpp-vault and dpp-node can see, following the workspace's dependency direction — and both sides call it. The store delegates to it; publish builds the declaration from it through a new snapshot_backup_url, extracted so the relationship is testable at all, which it was not before.

That is the difference between fixing the string and fixing the defect. The two halves lived in different crates with no shared definition, so they could drift apart independently and did.

Verified by putting the bug back. With the original {id}.json format restored, the test fails and names both halves:

the registry back-up URL must address the object the snapshot store writes;
declared `https://backup.example.com/dpp/01a06300-…-db56.json`,
store writes `01a06300-…-db56/public.json`

A trailing slash on the configured base is also handled — it previously produced a double slash, which is a different path to most static servers.

Two judgement calls to check

• The HTML sibling stays out of the declaration. The issue asked whether {dppId}/public.html belongs there. It does not, in my reading: the back-up link is consumed by machines and the JSON view is the one carrying the signatures a verifier needs. Recorded in snapshot_html_key's docs so the reasoning is where the next reader will look.
• .env.example now states a real constraint — whatever serves the base must expose the bucket's own layout, not a flattened one. The alternative (keep {id}.json and require a rewrite at the serving layer) makes correct configuration depend on a step nothing here performs or checks, and its failure is silent. Removing the requirement beats documenting it.

Scope

Latent rather than live: SNAPSHOT_PUBLIC_BASE_URL is unset by default and commented out, so no back-up link is declared at all today — its own gap, but a safe one. Nothing needs migrating; no passport carries a stored back-up URL.

Verification

just check green — 923/923, integration compile, audit and deny, REAL_EXIT=0 on the whole recipe.

Checklist

• Tests added or updated for new behaviour — the declared-URL/store-key relationship, plus trailing-slash handling; the first confirmed by watching it fail against the old format
• just lint passes locally
• just fmt applied
• just test passes (unit) — 923/923
• No println!/eprintln!/dbg! in service-crate src/
• No secrets, credentials, or .env files in the diff — .env.example only, a comment correction
• Docs updated — .env.example, and the reasoning on both key functions
• DB schema unchanged

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}