docs: ownership-and-templates names why a retired file is decided in the run that sees it go (#113)

Files changed:
- docs/ownership-and-templates.md

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

docs/ownership-and-templates.md

@@ -186,6 +186,18 @@ one an upgrade takes for them. The template-sourced files were filled in once, b
 a reason, and nothing about a newer release of the stack's mechanics gives it standing to
 override that.
 
+The same rule runs in the other direction, for a file a release stops shipping, and there it has
+a deadline the overwrite side does not. The stamp an upgrade writes is the new release's, and the
+path is no longer in it - so the next upgrade cannot tell that file from one the instance wrote
+itself, and an instance-owned file is exactly what an upgrade must never touch. Whatever happens
+to a retired file therefore happens in the run that sees it go, or not at all. An unchanged one is
+deleted as silently as an unchanged one is overwritten; a changed one is a local change like any
+other and needs the same deliberate answer, where keeping it makes it the instance's own for
+good. Leaving the decision optional, as it once was, did not defer it: it made it, the wrong way,
+and left orphans behind - harmless under `tools/`, where nothing discovers modules by listing a
+directory, and not harmless under `instructions/` or `types/`, where an orphaned skill keeps
+being published and an orphaned type-spec keeps being a type.
+
 ## Why an instance comes only from a release
 
 Everything above depends on one file every instance carries: the `.wikitool-release.json` its