docs: explain plugin installs from pre-release-only repositories

datumctl/plugins/building-plugins.mdx

@@ -9,7 +9,7 @@
 This guide walks through building a plugin in Go with the official SDK, `go.datum.net/datumctl/plugin`.
 
 <Info>
   The SDK reads only environment variables and execs subprocesses, so your plugin depends on it without pulling in any datumctl internals. A worked reference plugin lives at [`examples/plugin-dns`](https://github.com/datum-cloud/datumctl/tree/main/examples/plugin-dns) in the datumctl repository.
 </Info>
 
 ## The model
@@ -168,11 +168,11 @@
 
 ## Trust and verification for authors
 
 datumctl treats your plugin as untrusted code, which shapes how you distribute it:
 
 - **Ship checksums.** Whether users install from a catalog or directly from a GitHub release, datumctl verifies a SHA256 checksum before running your binary. Publish accurate checksums for every release archive.
 - **Managed installs are fingerprinted.** After install, datumctl records the binary's hash and re-verifies it on every run. Rebuilding or replacing the binary in place will cause datumctl to refuse it until it's reinstalled.
 - **A binary a user drops on their PATH is blocked by default.** datumctl will not run an unmanaged `datumctl-<name>` binary until the user explicitly trusts it with `datumctl plugin trust <name>`.
 
 ## Getting your plugin into a catalog
 
@@ -184,7 +184,7 @@
 datumctl plugin install your-org/datumctl-dns
 ```
 
-This path requires a `checksums.txt` alongside your release archives, in goreleaser's default two-column format.
+This path requires a `checksums.txt` alongside your release archives, in goreleaser's default two-column format. Tag releases with a semantic version such as `v1.2.3` or `v1.2.3-rc.1`. If you have published only pre-releases, datumctl installs the highest pre-release tag.
 
 ## Next steps
 

datumctl/plugins/using-plugins.mdx

@@ -75,6 +75,8 @@
 datumctl plugin install your-org/datumctl-example@v1.2.0
 ```
 
+Without a version, datumctl installs the release GitHub marks as latest. If the repository has published only pre-releases, datumctl installs the highest pre-release instead, and `datumctl plugin upgrade` follows newer pre-releases the same way.
+
 <Info>
   If a bare name exists in more than one catalog, datumctl lists the matches instead of guessing. Qualify the name with its catalog (for example `acme/deploy`) to choose.
 </Info>
@@ -147,7 +149,7 @@
 
 ## How plugins stay trustworthy
 
 datumctl treats a plugin as untrusted code and protects you in a few ways:
 
 - **HTTPS-only downloads.** Plugin archives and catalog manifests are fetched over HTTPS only. Downloads to private, loopback, or link-local addresses are refused, and redirects are re-checked on every hop.
 - **Checksum verification on every run.** datumctl records a SHA256 fingerprint of each plugin binary at install time and verifies it *every time the plugin runs*. If a managed plugin binary is modified after installation, datumctl refuses to run it.