fix(cloudflare): declare Container's network shape, and correct the documented example

[Cyberistic]

Fixes #1761.

What

Two changes, both needed:

1. The documented example is corrected — it used a key the API rejects.
2. Network is declared instead of inheriting unknown, which is what turns the mistake into a compile error rather than a deploy-time rejection.

The doc example could not work

// before
network: { assignIpv4: "predefined", mode: "public" },
// configuration.network: unrecognized key: "assignipv4"

It also could not fail any earlier: the generated schema types the whole object as unknown, and alchemy inherited that:

// @distilled.cloud/cloudflare/services/containers.ts
network?: unknown | null;
network: S.optional(S.NullOr(S.Unknown)),

So copying the example type-checked cleanly and only failed at deploy. The same is true of a key typed from memory.

What measuring showed

I ran real deploys varying only the network block (throwaway stack, --stage probe, destroyed afterwards), and the rules are tighter than the docs suggest:

network	Result
{ assignIpv4: "predefined" }	❌ unrecognized key: "assignipv4"
{ assign_ipv4: "predefined" }	❌ network.mode: "public" is not allowed for this account, only "private"
{ assign_ipv4: "predefined", mode: "private" }	❌ network.assign_ip: assigning an IP with network mode private is not allowed
{ assign_ipv4: "none", assign_ipv6: "none", mode: "private" }	✅ accepted

Two consequences the example did not convey, and which the type declaration and the docs notes now do:

• assign_ipv4: "predefined" implies mode: "public". With no mode given, the API inferred public and rejected it on an account restricted to private — so predefined is a public-networking request spelled in a different field, not a neutral "give it an address".
• assign_ipv4 and mode: "private" are mutually exclusive. Combined with the account restriction, a private-only account has no usable assign_ipv4 value at all and must set "none".

I have therefore replaced the example with the private shape (which deploys anywhere) rather than merely re-spelling the old one, and documented both rules on the type.

Network

Declared locally, for the same reason Constraints and Affinities already are in this file — the generated schema is opaque, so anything not declared here cannot be type-checked:

export type Constraints = { tier?: number };
export type Affinities = { colocation?: "datacenter" };
export type Network = {
  assign_ipv4?: "none" | "predefined";
  assign_ipv6?: "none" | "predefined";
  mode?: "private" | "public";
};

Tests

test/types/ContainerNetwork.ts, following the existing type-test convention (test/types/, checked by tsc -b). Each rule is a @ts-expect-error, which is a real check in both directions: if the type wrongly accepts, the directive itself becomes an error.

Verified both ways — against the inherited unknown the file reports 4 errors; with the declaration it compiles clean, and pnpm exec tsc -b is clean across the workspace.

Not done, deliberately

The type does not express the assign_ipv4 + mode: "private" exclusion, because Network is a single object type and that rule is a cross-field constraint. A union of accepted combinations could encode it, but that is a heavier change than a doc correction warrants and it would fight the optional-key ergonomics. Happy to do it if you would prefer the constraint enforced rather than documented.

Scope

Cloudflare.Container as declared for an image/context container (the .main/.image path); the effect-native .make() variant was not exercised.