fix: scope the TechLog CSRF invalidation to Studio operations

`contractOperations.execute` is the single executor every installed feature
dispatches through, and it called `invalidateTechLogCsrfOnOutcome` for every
operation. A 403 on an unrelated reference-feature request therefore threw
away a perfectly good TechLog CSRF token, forcing an avoidable
`getStudioSession` round trip on the next Studio operation -- and, when the
session endpoint is itself unhealthy, turning someone else's authorization
failure into a Studio outage.

`invalidateTechLogCsrfOnOutcome` now takes the operation's auth profile and
acts only on the two TechLog Studio profiles. Required, not optional, so the
scoping cannot be dropped again by omission, and the predicate lives in the
feature file: `bootstrap/runtime-adapters.ts` is template-synced and its
change is the one added argument.

The composition test now installs both contributions the way
`installed-contract-contributions.ts` does, and asserts a reference-feature
403 leaves the cached token alone. Reverting the scope check fails exactly
that test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/bootstrap/runtime-adapters.ts

@@ -585,7 +585,14 @@ export async function createRuntimeAdapters(
       // operation invalidates a token shared across all of them. Same call
       // the composition test drives
       // (`tests/features/tech-log/studio-csrf-composition.test.ts`).
-      invalidateTechLogCsrfOnOutcome(outcome.kind, techLogCsrf);
+      // The auth profile scopes it to Studio operations: this executor serves
+      // every installed feature, so without it an unrelated 403 discarded the
+      // TechLog token.
+      invalidateTechLogCsrfOnOutcome(
+        outcome.kind,
+        operation.frontend.authProfileId,
+        techLogCsrf,
+      );
       return outcome;
     },
   });