Adds the getting-started guide and runbook

Two guides, both required before a first release, written after the
envelope because a getting-started guide for an unimplemented package
is a promise rather than a document.

The getting-started guide stands up a single-key vault and then a
per-tenant one. It states where key material may come from - the
init/1 callback, never use options and never a config file - when to
configure 0x0478 and when to keep the signing default, and why
:max_age is required with no default: it is the answer to how long a
crypto-shred takes to take effect on a running node.

It requires two root secrets from day one, holding the same bytes. A
deployment that provisions both at install never performs P1 step 0,
which is the most destructive-looking no-op in the design: generating
a fresh reference root rather than copying moves every tenant
reference in the deployment.

The rotation runbook is the four procedures with their preconditions,
steps, independent verification and rollback, both blast radius
tables, and the two-vocabulary mapping across the packages. Every step
says whether it is a function this package ships or an action on a
store it does not own, and cache drainage is a step inside each
destructive procedure rather than a follow-up. It carries the honest
wording on shredding: a shred destroys plaintext, not attribution.

Every code block in both guides is executed by Encryptor.GuidesTest
against modules transcribed from the printed text, so a guide that
drifts from the landed surface fails the gate.

README reports the package as built rather than as a scaffold and
gives the installation form as a SHA-pinned git dependency; the
reserved 0.1.0 on Hex holds no implementation.

Refs: enc-nsi

Author: johnnyt

README.md

@@ -10,12 +10,23 @@ Ergonomic envelope encryption for Elixir - a vault module, pluggable key
 providers, and per-tenant keys - on the
 [aws_encryption_sdk](https://hex.pm/packages/aws_encryption_sdk) engine.
 
-## Status: designed, not built
+## Status: built, not released
 
 The five founding architecture decision records were **accepted on
-2026-08-27**. They fix the contracts this package is made of. **No
-implementation has landed yet**: `lib/` holds a moduledoc, the package is not
-published, and nothing below is a promise about a function you can call today.
+2026-08-27**. They fix the contracts this package is made of, and the vault
+core and the per-tenant envelope are implemented against them: the `use
+Encryptor.Vault` macro and its supervision tree, the configuration freeze,
+`encrypt/2`, `decrypt/2`, `rekey/2`, the key-provider behaviour with its
+`Static` and `Function` adapters, `Encryptor.Envelope`'s
+`provision/3`/`unwrap/2`/`rewrap/2`, and `Encryptor.Message.describe/1`.
+
+**Nothing is released.** The package is not published to Hex - the reserved
+`encryptor 0.1.0` there is a name reservation holding no implementation - so
+consume it as a git dependency until the first real release. See
+[Installation](#installation).
+
+Start with the **[getting-started guide](guides/getting-started.md)** and the
+**[rotation runbook](guides/rotation-runbook.md)**.
 
 | Record | Decides |
 |---|---|
@@ -100,15 +111,32 @@ open and the design works around both until they move:
 
 ## Installation
 
+The package is **not published to Hex**. `encryptor 0.1.0` on Hex is a name
+reservation and holds no implementation; do not depend on it. Until the first
+real release, consume this package as a git dependency pinned to a full SHA:
+
 ```elixir
 def deps do
   [
-    {:encryptor, "~> 0.1"}
+    {:encryptor, github: "riddler/encryptor", ref: "<full 40-character sha>"}
   ]
 end
 ```
 
-Not yet published to Hex.
+Pin a SHA rather than a branch. A moving dependency on a package that decides
+ciphertext layout is a package that can change what your stored rows mean
+between two `mix deps.get` runs.
+
+## Guides
+
+- **[Getting started](guides/getting-started.md)** - a single-key vault and a
+  per-tenant vault, where key material is allowed to come from, why a host
+  chooses `0x0478`, why `max_age` has no default, and the two root secrets a
+  deployment provisions on day one.
+- **[Rotation runbook](guides/rotation-runbook.md)** - the four operator
+  procedures, what each step destroys, which steps this package ships as
+  functions and which are actions on a store it does not own, and what a
+  crypto-shred does and does not achieve.
 
 ## License
 

changelog.d/enc-nsi.md

@@ -0,0 +1,41 @@
+### Added
+
+- A getting-started guide (`guides/getting-started.md`): a single-key vault and
+  a per-tenant vault, stood up from nothing. It states where key material is
+  allowed to come from (the `init/1` callback, never `use` options and never a
+  config file), when to configure the unsigned `0x0478` suite and when to keep
+  the signing default, and why `:max_age` is required with no default - it is
+  the answer to how long a crypto-shred takes to take effect on a running node.
+- The guide requires **two root secrets from day one, holding the same bytes**:
+  a pinned reference root that is never rotated, and a wrapping root that
+  procedure P1 rotates. A deployment that provisions both at install never has
+  to perform P1's copy-the-reference-root step, which is the most
+  destructive-looking no-op in the design - generating a fresh value there
+  instead of copying changes every tenant reference in the deployment.
+- A rotation runbook (`guides/rotation-runbook.md`): the four operator
+  procedures - root rotation, tenant key rotation, tenant shred, version retire
+  - each with its preconditions, steps, independent verification and rollback,
+  plus both blast radius tables. Every step is labelled with whether it is a
+  function this package ships or an action on a store it does not own, and
+  cache drainage is a step inside each destructive procedure rather than a
+  follow-up.
+- The runbook carries the two-vocabulary mapping table across `encryptor` and
+  `encryptor_ecto`, because the two packages name the three key levels
+  differently and an operator reading one runbook against the other's names can
+  run a level 2 rotation believing it is a level 1 rotation.
+- The runbook states plainly what a crypto-shred does not destroy: **a shred
+  destroys plaintext, not attribution**. The tenant pseudonym in every message
+  header is permanent, and the holder of the reference subkey can re-identify
+  it by guess-and-confirm forever, in every retained backup. Deleting the
+  tenant's ciphertext rows is compliance-mandatory wherever tenant attribution
+  is itself personal data, and the shred claim must never be stated as full
+  erasure.
+- Both guides are ExDoc extras, and every code block in them is executed by
+  `Encryptor.GuidesTest` against modules transcribed from the printed text.
+
+### Changed
+
+- `README.md` reports the package as built rather than as a scaffold, links
+  both guides, and gives the installation form as a SHA-pinned git dependency.
+  The reserved `encryptor 0.1.0` on Hex is a name reservation holding no
+  implementation and must not be depended on.