docs(motoko): align Candid regeneration to mops generate candid backend (#1450)

* docs(motoko): use `mops generate candid backend` for Candid regeneration

Align the "Updating the Candid interface" instructions across all Motoko
examples to use `mops generate candid backend` (the canister name defined
in `mops.toml`) instead of the low-level
`$(mops toolchain bin moc) --idl -o ...` invocation.

Also add the missing section to the two vetkeys examples whose frontends
generate bindings from `backend/backend.did` via `@icp-sdk/bindgen`
(encrypted_notes_app_vetkd, password_manager_with_metadata).
password_manager is intentionally left out — its frontend talks to the
backend via the Encrypted Maps client and does not consume the `.did`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(vetkeys): drop unused committed Candid file from password_manager

The password_manager frontend talks to the backend purely through the
`@icp-sdk/vetkeys` Encrypted Maps client and does not consume
`backend/backend.did` (no `@icp-sdk/bindgen`, no generated bindings).
Nothing else references the file, and `moc` generates the Candid
interface as canister metadata at build time regardless.

Remove the committed `backend/backend.did` and the now-unused
`candid = "backend/backend.did"` line from `mops.toml`, matching the
backend-only convention used elsewhere in the repo. Verified with
`icp build` — the built wasm still embeds `icp:public candid:service`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: marc0olo

motoko/cert-var/README.md

@@ -52,7 +52,7 @@ npm run dev --prefix frontend
 If you change the Motoko source, regenerate `backend/backend.did`:
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/daily_planner/README.md

@@ -35,7 +35,7 @@ npm run dev
 ## Updating the Candid interface
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/filevault/README.md

@@ -40,10 +40,10 @@ npm run dev
 
 The `backend/backend.did` file defines the backend canister's public interface. The frontend TypeScript bindings are auto-generated from this file during the frontend build.
 
-If you modify the backend's public API, regenerate the `.did` file using the Motoko compiler:
+If you modify the backend's public API, regenerate the `.did` file:
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/flying_ninja/README.md

@@ -39,7 +39,7 @@ The `backend/backend.did` file defines the backend canister's public interface.
 If you modify the backend's public API, regenerate the `.did` file:
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/hello_world/README.md

@@ -62,10 +62,10 @@ icp network stop
 
 The `backend/backend.did` file defines the backend canister's public interface. The frontend TypeScript bindings are auto-generated from this file during the frontend build.
 
-If you modify the backend's public API, regenerate the `.did` file using the Motoko compiler:
+If you modify the backend's public API, regenerate the `.did` file:
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/random_maze/README.md

@@ -39,7 +39,7 @@ npm run dev --prefix frontend
 ## Updating the Candid interface
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/superheroes/README.md

@@ -40,10 +40,10 @@ npm run dev
 
 The `backend/backend.did` file defines the backend canister's public interface. The frontend TypeScript bindings are auto-generated from this file during the frontend build.
 
-If you modify the backend's public API, regenerate the `.did` file using the Motoko compiler:
+If you modify the backend's public API, regenerate the `.did` file:
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/vetkeys/basic_vetkd/README.md

@@ -37,7 +37,7 @@ Open the frontend URL printed by `icp deploy`. When done: `icp network stop`
 ## Updating the Candid interface
 
 ```bash
-$(mops toolchain bin moc) --idl -o backend/backend.did backend/app.mo
+mops generate candid backend
 ```
 
 ## Security considerations and best practices

motoko/vetkeys/encrypted_notes_app_vetkd/README.md

@@ -56,6 +56,14 @@ A single Motoko canister that stores encrypted notes. It is deployed automatical
 
 A **Svelte** application providing a user-friendly interface for managing encrypted notes. Canister bindings are generated from `backend/backend.did` at build time by the `@icp-sdk/bindgen` Vite plugin.
 
+## Updating the Candid interface
+
+`backend/backend.did` defines the backend's public interface; the frontend bindings are generated from it during the build. If you change the backend's public API, regenerate it:
+
+```bash
+mops generate candid backend
+```
+
 ## Limitations
 
 This example app does not implement key rotation, which is strongly recommended in a production environment.