Migrate ConfigKit to its vanity module path

docs/consumers/README.md

@@ -6,6 +6,9 @@ applications. Consumers still own their configuration structs, defaults, semanti
 validation, schema-version policy, CLI parsing, runtime matching and conversion,
 resource checks, remote acquisition, and service initialization.
 
+Import the public root package as `"go.maximumdirect.net/configkit"`; its package
+name remains `configkit`.
+
 ## Choosing a loading entry point
 
 - Use [`Load`](../../lifecycle.go) with one source for an ordinary configuration.
@@ -311,6 +314,26 @@ The examples preserve domain meaning while adopting one configuration convention
   blocked empty variables remain blocked, and ordinary `Load` never changes the
   process environment.
 
+### Vanity module path migration
+
+ConfigKit's module identifier changed from
+`gitea.maximumdirect.net/eric/ConfigKit` to `go.maximumdirect.net/configkit` before
+v1.0.0. Update the dependency requirement in your application's `go.mod` and its
+Go imports together, selecting a revision or release that declares the new module
+path. The package name remains `configkit`; the configuration model and public
+symbol names are unchanged by this identity migration.
+
+Old and new import paths identify distinct Go packages, including distinct named
+types. Coordinate adoption with any dependencies that exchange ConfigKit values
+with your application; changing a requirement alone does not make those types
+interchangeable. The maintained examples use the new path, but other repositories
+must manage their own migrations.
+
+Historical tags keep their original module declarations and contents. Older
+releases such as v0.10.2 still use the old path and cannot be installed under the
+vanity identifier simply because discovery can find their repository. A matching
+migrated revision is needed; no old-path compatibility module is supplied here.
+
 ### Pre-v1 public API cleanup
 
 The pre-v1 API cleanup replaces these names outright; it does not retain