fix(fleet): carry a site's TLS material when it moves

docs/cli.mdmodified+20-0

Changes to docs/cli.md

		⋯232 linesShow the 232 lines above this hunk@@ -233,6 +233,26 @@ Like the tree snapshot, the dump is re-taken on a resume rather than skipped: on
233	233	from an earlier attempt predates whatever the source has committed since, and
234	234	shipping stale rows is worse than dumping twice.
235	235
	236	+#### TLS
	237	+
	238	+Certificates live in the gateway's cert directory (`/etc/rpx/certs` by default),
	239	+which belongs to the box rather than to the site — the same shape as an on-box
	240	+database, and the same failure if left behind. The move carries the certificate
	241	+and private key for the site's domain and every alias, **before** it routes the
	242	+site and well before DNS: a hostname that resolves to a box holding no
	243	+certificate for it is refused by every browser, which is a worse outcome than the
	244	+site simply still being on the old box. Private keys are restored `0600`.
	245	+
	246	+Whether the target already has them is decided by checksum, not by whether a file
	247	+exists — an older certificate for the same hostname, expired or issued while the
	248	+domain pointed somewhere else, is not the one being moved. A hostname the source
	249	+has no certificate for is skipped rather than blocking: a site behind on-demand
	250	+TLS may legitimately have none yet, and the target re-issues on first request.
	251	+
	252	+Renewal is not carried. The per-project renewal timer is written by the normal
	253	+provisioning path, so the next `cloud deploy` against the target establishes it;
	254	+until then the carried certificates stand on their own remaining validity.
	255	+
236	256	The archive travels through the machine running the command rather than directly
237	257	between the boxes: a direct hop would need the target to hold a credential for
238	258	the source, which is the same credential-radius problem consolidation already