Prove the bake's answer writes by reading the key back

SetProjExtState's return covers the whole extname, so it never saw one key. The persist verdict now reaches the report, and a throw mid-write no longer claims the landing left nothing behind.

src/shell/instrument/instrument_bake.cpp

@@ -196,9 +196,9 @@ BakeChainResult runBake(ReaSamplerProcessor& processor) {
 
     // What the key holds now is the only evidence this side gets, and each of the five
     // non-answers is a different thing to go fix — collapsing them into one sentence is
-    // what made a stale install indistinguishable from a refusal. The three that are about
-    // the KEY name it, because the landing prints one console line per key it scanned and
-    // the key is what correlates the two in a multi-instance session.
+    // what made a stale install indistinguishable from a refusal. All five name the KEY,
+    // because the landing prints one console line per key it scanned and the key is what
+    // correlates the two in a multi-instance session.
     const wire::BakeAnswer answer =
         wire::classifyBakeAnswer(bridge.readReasamplerExtState(key), request);
     switch (answer.kind) {
@@ -210,9 +210,9 @@ BakeChainResult runBake(ReaSamplerProcessor& processor) {
                         "landing action prints one REAPER console line per key it "
                         "scanned; look for that key name there");
         case wire::BakeAnswerKind::Undecodable:
-            return fail(
-                "the extension answered in a format this plugin does not read -- the "
-                "extension and ReaSampler 9000 are from different builds");
+            return fail("the value under " + key +
+                        " is neither a request nor an answer this build can read -- the "
+                        "extension and ReaSampler 9000 may be from different builds");
         case wire::BakeAnswerKind::Cleared:
             return fail("the bake key " + key +
                         " came back empty -- either the request was cleared before an "
@@ -225,7 +225,8 @@ BakeChainResult runBake(ReaSamplerProcessor& processor) {
                         "unexpected given the bake's single-threaded call flow; if this "
                         "recurs, note the exact steps and file it");
         case wire::BakeAnswerKind::ForeignOutcome:
-            return fail("the extension answered a different bake request");
+            return fail("the answer under " + key +
+                        " is for a different bake request than this one");
     }
     // wire::answeredOutcome is the guard, not switch exhaustiveness alone: the switch
     // above has no `default`, so a future BakeAnswerKind enumerator it doesn't yet handle