chore: bump source submodules and update docs for icp-cli v1.0.0 (#297)

## Summary

Bumps pinned source submodules and updates docs to match. Driven by the
icp-cli v1.0.0 release.

### Submodule bumps
- `icp-cli` v0.3.1 → **v1.0.0** (`.sources/VERSIONS` updated)
- `icp-cli-recipes`, `icp-cli-templates`, `icskills` → latest `main`
- `icp-js-sdk-docs` already at tip

### icp-cli v1.0.0
- `--set-controller` was removed; `settings.mdx` now uses
`--remove-all-controllers` combined with `--add-controller`.

### Motoko recipe v5.0.0
The recipe now compiles via `mops build`, so the source file, Candid
file, and compiler args move from the recipe `configuration:` block into
`mops.toml`. Updated in `project-structure.mdx`, `candid.mdx`,
`optimization.md`, and `ethereum.mdx`. The GC-options example now shows
a real legacy-persistence alternative (`--legacy-persistence` +
`--compacting-gc`) rather than the now-default `--incremental-gc`.

### Latest recipes
- Rust recipe pins → **v3.3.0**; redundant `package` dropped where it
equals the canister name (v3.3.0 defaults it), with an explanatory note
kept in the getting-started page.
- asset-canister `v2.2.1` and prebuilt `v2.0.0` already current.

### Mainnet domain → `icp.net` / `id.ai`
The icp-cli mainnet **HTTP gateway** domain is now `icp.net` (was
`icp0.io`). Browser/canister-access URLs, `raw.*` domains, the
`custom-domains/v1/` API, live canister links, and the NNS app
(`nns.ic0.app` → `nns.icp.net`) were updated across the docs (all
verified resolving). The Internet Identity service link now points to
its canonical `https://id.ai`.

Deliberately left unchanged (these are not the gateway):
- JS `HttpAgent` / agent API hosts — the **API** endpoint is
`icp-api.io`/`icp0.io`, separate from the gateway.
- The Internet Identity `icp0.io` ↔ `ic0.app` delegation-rewriting
behavior.
- The verifiable-credentials `iss` (issuer) claim — a protocol
identifier that must match what II signs (already flagged for human
verification).

Reconciling the icskills to `icp.net` is tracked in
dfinity/icskills#224.

### Other
- Fixed a pre-existing broken link in `edge-infrastructure.md`
(`http-gateway-spec.md` → `http-gateway-protocol-spec.md`) surfaced by
validation, plus minor lint cleanup (em-dash, `mo:base` reference) in
files touched here.

## Notes
- `npm run build` and `scripts/validate.js` both pass (209 pages).
- Changes were reviewed by a subagent against `.sources/` with no
must-fix findings.
- ⚠️ Possible merge conflict with #252 (also edits `settings.mdx`, in a
different section).

Author: marc0olo

.sources/VERSIONS

@@ -56,7 +56,7 @@
 chain-fusion-signer   v0.4.0                                                    a18c52a
 papi                  v0.1.1                                                    168bc9d
 ic-pub-key            v1.0.1                                                    f89fa55
-icp-cli               v0.3.1                                                    c4c4618
+icp-cli               v1.0.0                                                    9eed60c
 motoko                v1.9.0                                                     e7c78d7
 motoko-core           v2.4.0                                                    cd37dbf
 cdk-rs                ic-cdk v0.20.1 / ic-cdk-timers v1.0.0 / ic-cdk-executor v2.0.0  317f55c

.sources/icp-cli

@@ -33,13 +33,13 @@ Around 20 API boundary nodes are currently deployed worldwide. An up-to-date lis
 
 HTTP gateways translate standard HTTP requests into IC API calls and forward them to API boundary nodes. Because of this translation layer, browsers and other HTTP clients can access canisters directly without installing any special software. For example, a website fully hosted on ICP is accessible in any browser through a normal HTTPS URL.
 
-The HTTP Gateway Protocol (defined in the [HTTP Gateway Protocol Specification](../references/http-gateway-spec.md)) specifies exactly how this translation works. HTTP gateways are not part of ICP itself and can be operated by anyone. This open model encourages a diverse set of gateways, enhancing redundancy and availability.
+The HTTP Gateway Protocol (defined in the [HTTP Gateway Protocol Specification](../references/http-gateway-protocol-spec.md)) specifies exactly how this translation works. HTTP gateways are not part of ICP itself and can be operated by anyone. This open model encourages a diverse set of gateways, enhancing redundancy and availability.
 
 ## HTTP Gateway Protocol
 
 When a browser opens a URL hosted by a canister, the following happens:
 
-1. The browser makes a normal HTTPS request to the domain (for example, `https://<canister-id>.icp0.io`). It has no awareness that the site runs on ICP.
+1. The browser makes a normal HTTPS request to the domain (for example, `https://<canister-id>.icp.net`). It has no awareness that the site runs on ICP.
 2. The HTTP gateway receives the request and translates it into a query call to the canister's `http_request` method, placing the path, headers, and body into the call payload.
 3. An API boundary node receives the IC API call and forwards it to a replica on the subnet that hosts the target canister.
 4. The canister executes the `http_request` query, constructs an HTTP response (status, headers, body), and returns it.
@@ -66,7 +66,7 @@ For practical guidance on certifying canister responses, see [Certified variable
 
 ## Further reading
 
-- [HTTP Gateway Protocol Specification](../references/http-gateway-spec.md): detailed protocol definition
+- [HTTP Gateway Protocol Specification](../references/http-gateway-protocol-spec.md): detailed protocol definition
 - [ic-http-gateway library](https://github.com/dfinity/ic-http-gateway-protocol/tree/main/packages/ic-http-gateway-protocol): the main implementation of the HTTP Gateway Protocol
 - [response-verification](https://github.com/dfinity/response-verification): libraries for certifying canister responses to work with the HTTP gateway protocol
 - [Certified variables guide](../guides/backends/certified-variables.md): how to certify canister responses

.sources/icp-cli-recipes

@@ -15,7 +15,7 @@ ICP has four protocol-level uses:
 
 **2. Cycle conversion.** ICP can be burned to mint cycles through the Cycles Minting Canister (CMC). Cycles are pegged to the XDR basket of currencies at a rate of 1 trillion cycles = 1 XDR. This means developer infrastructure costs are stable in fiat terms even as ICP's market price changes. See [Cycles](cycles.md) for details.
 
-**3. Node provider rewards.** Nodes that run the Internet Computer are owned by independent node providers. These providers are compensated in newly minted ICP. Rewards are specified in XDR and converted to ICP based on a 30-day moving average exchange rate, so providers receive stable real-world compensation regardless of price fluctuations. The Cycles Minting Canister (CMC) fetches the ICP/XDR rate every 5 minutes from the [exchange rate canister](chain-fusion/exchange-rate-canister.md#how-rates-are-computed), which aggregates rates from external sources. It uses the start-of-day rates for the past 30 days to compute the moving average. The current conversion rate is available on the [ICP dashboard](https://dashboard.internetcomputer.org/network) and from the [CMC metrics endpoint](https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp0.io/metrics).
+**3. Node provider rewards.** Nodes that run the Internet Computer are owned by independent node providers. These providers are compensated in newly minted ICP. Rewards are specified in XDR and converted to ICP based on a 30-day moving average exchange rate, so providers receive stable real-world compensation regardless of price fluctuations. The Cycles Minting Canister (CMC) fetches the ICP/XDR rate every 5 minutes from the [exchange rate canister](chain-fusion/exchange-rate-canister.md#how-rates-are-computed), which aggregates rates from external sources. It uses the start-of-day rates for the past 30 days to compute the moving average. The current conversion rate is available on the [ICP dashboard](https://dashboard.internetcomputer.org/network) and from the [CMC metrics endpoint](https://rkp4c-7iaaa-aaaaa-aaaca-cai.raw.icp.net/metrics).
 
 **4. SNS decentralization swaps.** Users can commit ICP to participate in the decentralization swap of an SNS. In return they receive the SNS's governance assets at a uniform price. The ICP raised enters the SNS treasury under NNS control and funds future development and operations.
 

.sources/icp-cli-templates

@@ -42,7 +42,7 @@ For how the protocol achieves this (block making, notarization, finalization, an
 
 Boundary nodes are the entry point for all external traffic to ICP. They serve two purposes:
 
-1. **HTTP gateway.** When a user's browser requests `https://<canister-id>.icp0.io`, a boundary node translates that HTTP request into a canister message, routes it to the correct subnet, and returns the response.
+1. **HTTP gateway.** When a user's browser requests `https://<canister-id>.icp.net`, a boundary node translates that HTTP request into a canister message, routes it to the correct subnet, and returns the response.
 2. **API endpoint.** Agent libraries (like [`@icp-sdk/core/agent`](https://js.icp.build/core/latest/libs/agent) in JavaScript) send ingress messages to boundary nodes, which forward them to the target canister's subnet.
 
 Boundary nodes also cache query responses and provide TLS termination. They are not part of consensus and cannot modify canister state: they are routing infrastructure.

.sources/icskills

@@ -13,7 +13,7 @@ ICP defines five principal classes, though one (derived IDs) has never been impl
 
 **2. Canister IDs:** Each canister on ICP has a unique principal derived when the canister is created. Canister principals look like `ryjl3-tyaaa-aaaaa-aaaba-cai`. When a canister makes a call to another canister, the callee sees the calling canister's canister ID as the caller principal.
 
-**3. Self-authenticating IDs:** User identities are derived from public keys using a domain-separated hash. Anyone holding the corresponding private key can authenticate and call canisters under that principal. Self-authenticating principals look like `o2ivq-5dsbb-hhfso-w2o5v-7qiaq-g4fbm-6qhhb-xbj6w-szpxa-lflfa-mae` for Ed25519 keys or similar for ECDSA keys. The [Internet Identity](https://identity.ic0.app/) service manages key-backed identities for end users.
+**3. Self-authenticating IDs:** User identities are derived from public keys using a domain-separated hash. Anyone holding the corresponding private key can authenticate and call canisters under that principal. Self-authenticating principals look like `o2ivq-5dsbb-hhfso-w2o5v-7qiaq-g4fbm-6qhhb-xbj6w-szpxa-lflfa-mae` for Ed25519 keys or similar for ECDSA keys. The [Internet Identity](https://id.ai/) service manages key-backed identities for end users.
 
 **4. Anonymous principal (`2vxsx-fae`):** Messages that are not signed use the anonymous principal as their caller identity. Any canister can check whether a caller is anonymous and decide how to handle unsigned requests (for example, allowing public reads but rejecting state changes from anonymous callers).
 

docs/concepts/edge-infrastructure.md

@@ -82,15 +82,22 @@ Each canister has its own `canister.yaml` that defines how to build and deploy i
 
 <Tabs syncKey="lang">
 <TabItem label="Motoko">
-The Motoko backend uses the `@dfinity/motoko` recipe:
+The Motoko backend uses the `@dfinity/motoko` recipe, which compiles via `mops build`:
 
 ```yaml
 name: backend
 recipe:
-  type: "@dfinity/motoko@v4.1.0"
-  configuration:
-    main: src/main.mo
-    candid: backend.did
+  type: "@dfinity/motoko@v5.0.0"
+```
+
+The recipe takes no source or Candid configuration. Instead, the source file (and optionally the Candid file and compiler flags) are declared in a `mops.toml` at the project root. The `[canisters]` key must match the canister `name`:
+
+```toml
+[toolchain]
+moc = "1.9.0"
+
+[canisters]
+backend = "src/main.mo"
 ```
 </TabItem>
 <TabItem label="Rust">
@@ -99,12 +106,13 @@ The Rust backend uses the `@dfinity/rust` recipe:
 ```yaml
 name: backend
 recipe:
-  type: "@dfinity/rust@v3.2.0"
+  type: "@dfinity/rust@v3.3.0"
   configuration:
-    package: backend
     shrink: true
     candid: backend.did
 ```
+
+The `package` parameter (the Cargo package to build) defaults to the canister `name`, so it can be omitted when they match. Set it explicitly only when they differ.
 </TabItem>
 </Tabs>