Decide whether the key store is wrapped with a key of its own

[iderex]

docs/keystore.md now states what protects the store at rest: the two Unix modes set at creation where the platform has them, the operator's access control on the data directory everywhere, and nothing else. That closed #31, whose three conditions were about stating the position. It did not answer the sentence in #31's body that says encrypting the store with a key kept beside it "is still worth doing", and that sentence needs a home rather than a paragraph in a document.

The question

Whether this plugin wraps the key store's contents with a key of its own, and if so:

• where the wrapping key lives, given that it cannot live inside the file it wraps
• what a server does when the store is present and the wrapping key is not, which is the case that decides whether this fails closed or destroys a working pairing
• what happens on the reverse, a wrapping key present and a store from before the layer existed

What is already settled and should not be re-argued

What it would buy. Protection against somebody who takes one file and not the other, and nothing else. A process running as the server's user reads both. A filesystem backup that copied the data directory carries both. That is written in docs/keystore.md under what protects it at rest, with the residual risk section beside it naming what A5, A6 and A8 obtain today.

What the host offers. Nothing. Measured at both supported server lines rather than assumed:

git rev-parse v10.11.9 v12.0-rc3
e83a7e62f26443f7dd98f126d6955ac1af090125
fc43f151a2418cc112e116050a99dd6318917ab0

git grep -l 'IDataProtectionProvider\|AddDataProtection' v10.11.9 v12.0-rc3 -- '*.cs' ; echo "exit=$?"
exit=1

so whatever wraps this store, this plugin brings.

What the primitive may be. docs/crypto.md refuses any primitive implemented in this repository, so the answer is a call the base class library already ships or it is not this repository's answer:

git grep -n '^## What is deliberately absent' -- docs/crypto.md

Why this is not simply picked up next

Two issues decide how bytes on this path are read and neither has landed. The store carries no format version, which is #55, and it has no answer for a file that does not parse, which is #33. A wrapping layer landing before those is a layer the format work then has to migrate and the corruption work then has to tell apart from damage - a wrapped file and a corrupt one look identical to a reader that has neither.

So the ordering is part of the question rather than a detail of it: this either waits for #55 and #33, or it is taken first and those two are written against a wrapped file from the start.

Done when

• the decision is recorded, either as a wrapping layer that exists or as a written refusal to add one with the reason
• if it is added, docs/keystore.md's at-rest section and its residual risk rows say what changed and what did not, and no row of that section becomes a positive assurance
• if it is refused, docs/keystore.md says the question was taken and closed rather than leaving a reader to assume nobody looked

[iderex]

Deciding both halves.

Yes, the store is wrapped, and the ordering is: #55 and #33 first, then the wrapping layer. Wrapping an unversioned file that has no answer for being unparseable would hand both of those issues a harder problem than they were written for - #55 would have to migrate an already-wrapped file, and #33 would have to distinguish a corrupt store from a correctly-encrypted one it cannot read, which is precisely the confusion that makes at-rest protection dangerous rather than useful. A format version and a defined answer for a file that does not parse are what make wrapping legible.

The answers the wrapping layer is built to, recorded now so the two prior issues can be shaped for them: the wrapping key lives in the platform key store, never in or beside the file it wraps; a store present with no wrapping key is a hard refusal to start, stated in the log with what is missing, never a silent fall back to reading it unwrapped; and a wrapping key present with a store that predates the layer is a one-way migration on first read, which is legible only because #55 has given the file a version to compare. The primitive is one the base class library already ships, per docs/crypto.md - nothing cryptographic is implemented in this repository.

docs/keystore.md records the decision and the ordering now, so a reader does not have to infer from the absence of a layer that nobody looked. Unblocking; this issue's work begins when #55 and #33 land.