Retire only after ten minutes as well as five passes, and never through remove

Five passes are 25 s, shorter than a real hiccup. And a provider's remove can
destroy — a ledger file, a public DNS record — so an adapter without a retire
of its own is mark-only: the consumer keeps its access, is marked and said, and
remove is reached only by a person's delete (hq ADR 0230).

README.md

@@ -29,17 +29,20 @@ module. This is the ADR 0039 line drawn through provisioning: stable loop here,
 in the module.
 
 **A consumer the mesh stops asking for is retired, not withdrawn whole** (novox/hq ADR 0230). ACTIVE
-becomes RETIRED — access disabled through the adapter's `retire` (or `remove`, for an adapter that
-has none), marked with when and why, nothing deleted — only once the same set of consumers has gone
-unasked in five consecutive passes that read the file (20 s at the default 5 s interval; a pass that
-cannot read the file resets the count). A stable set of more than 3, or more than half of those held
-where more than one is held, is not retired without a person: the provider waits for
+becomes RETIRED only once the same set of consumers has gone unasked in five consecutive passes that
+read the file AND for ten minutes (`stableForMs`, `STABLE_FOR_MS`; a pass that cannot read the file
+starts both again). An adapter with `retire` disables the consumer's access, reversibly, and marks it;
+`reenable` (optional) undoes that before `create` when it is asked for again. **An adapter without
+`retire` is mark-only**: nothing in the backend changes — the consumer keeps its access — and the
+harness marks it "retired, access kept, needs deletion", says so loudly and announces it. **`remove` is
+never called to retire**; it is the delete of an adapter without `delete`, reached only through a
+person's `provisioner_delete`. A stable set of more than 3, or more than half of those held where more
+than one is held, is not retired without a person: the provider waits for
 `provisioner_retire_approve` or `provisioner_retire_reject`, and says `provisioner.retirement`
 (`waiting`) through the `announce` option. Asked for again, a retired consumer is created — re-enabled
-— at once. DELETED only through `provisioner_delete`, of a retired consumer. Given `module`, the four
-tools (`provisioner_retirement`, `provisioner_retire_approve`, `provisioner_retire_reject`,
-`provisioner_delete`) are registered for it; `provisionerTools(handle)` builds them otherwise.
-Additions and changes are never delayed.
+— at once. Given `module`, the four tools (`provisioner_retirement`, `provisioner_retire_approve`,
+`provisioner_retire_reject`, `provisioner_delete`) are registered for it; `provisionerTools(handle)`
+builds them otherwise. Additions and changes are never delayed.
 
 ### `tools` — the tool-serving harness
 `registerModuleTools`, the `ToolDefinition` type, and the registry/worker that loads a module's