Name the case where a catalog key holds a property name

[Jeehut]

What changes

MigrationGuide.md, section "The context part": one new bullet after "Properties contribute NOTHING". It names the case where a catalog key does contain the enclosing property name, and states that the catalog key wins.

Why

The removed macro (TranslationKey.semanticKey) did append property names when the compiler listed a VariableDeclSyntax in lexicalContext. Most toolchains never did, so the "properties contribute nothing" rule held for most catalogs, but not for all. A real migration of the TranslateKit app hit it: the same unchanged source produced two different key sets depending on when the catalog was extracted.

Evidence from the app's Localizable.xcstrings (catalog sync commit, Oct 2026), source unchanged in between – the call sits inside var userFriendlyMessage: String of BookmarkManager.BookmarkError:

-    "BookmarkManager.BookmarkError.theURLIsNotAValidFileURL" : {
+    "BookmarkManager.BookmarkError.UserFriendlyMessage.theURLIsNotAValidFileURL" : {

All six error keys in that property moved the same way. A migration that followed the derivation rule alone would have written the old form and orphaned all six translations; following "catalog first" gives the right key. The guide now says so explicitly instead of leaving it to luck.

Alternatives considered

• Rewriting the rule to "properties contribute their name" – wrong for most existing catalogs; the derivation must stay as the default.
• Leaving it to the "catalog first" rule – correct in principle, but the absolute "NOTHING" invites an agent to "fix" a catalog key that looks off. Naming the case closes that gap.

Proof

Docs-only change. Verified against the TranslateKit app: its migrated BookmarkManager.swift uses the UserFriendlyMessage keys verbatim, and all six messages showed as English text, none as raw keys, in a QA run of the app.