Locking + sanity check process

- [ ] Locking + sanity check process:
- [ ] 1. Before, optionally (based on conf) do sanity Detector check
- [ ] 2. After, optionally (based on conf) do sanity Detector check
- [ ] 3. After, (required) make output all exclusively readonly,
recursively in the case of a directory
- [ ] 4. `Resource` base class should treat writable caches as
non-existent, thus making "in progress" files unusable to front-end
services. This step is essential for data integrity.
- [ ] Obsolete Detector Converter types, I believe

Begin by locating the Resource base class and the Detector and Converter types mentioned in the checklist, then trace how resources and caches are exposed to front-end services. Clarify the configuration points and existing locking or sanity-check behavior before deciding how each checklist item should be verified. Done means the locking, readonly output, writable-cache handling, and obsolete-type decisions are specified and covered by appropriate checks.

Written by the indexing model from the issue text.