清掉 v2 白名單裡 6 個資料庫不存在的欄位，並加上機械化守衛

[frankslin]

Closes #1284

問題

allowedFields() 是一份手寫清單，與資料表的實際欄位之間沒有任何保證。列進去卻不存在的欄會被白名單放行，錯誤要到 DB::table()->update()／->insert() 才發生 ⇒ 使用者拿到 500 而不是 422。而 API.md 又照著白名單把它們公布為對外契約，外部協作者照文件實作就會撞 500。

清掉的 6 欄

表	欄位	來源
ALTNAME_DATA	c_alt_name_pinyin、c_alt_name_pinyin2、c_alt_name_pinyin3、c_alt_name_role	#1284
BIOG_TEXT_DATA	c_supplement、c_text_year	本 PR 新增的守衛抓到的

六欄 migration 均未曾建立（baseline import_cbdb_schema.php 的 ALTNAME_DATA 就是 12 欄），prod 也查不到。c_text_year 屬於 TEXT_CODES，走 text-codes 聚合端（ResolvesTextAggregateInput），本來就不該出現在 BIOG_TEXT_DATA 的白名單裡。

同一類的「幻影 c_supplement」先前已在 AssociationMutationHandler／KinshipMutationHandler／PossessionMutationHandler 逐一手工清掉過（原碼註解仍在），BIOG_TEXT_DATA 這筆漏網——這正說明手工核對不夠。

為什麼半年沒被發現

6 支測試檔各自在合成表裡把這些欄建了出來：ApiV2CreateAltnameTest、ApiV2MutateAltnameTest、ApiV2DeleteAltnameTest、ApiV2MutateVariantReplacementTest、ProposalResubmitTest、ProposalAuditFieldSemanticsTest、VariantReplaceScopeTest。於是整條 PinyinUmlaut Tier 1 的 ALTNAME 分支（lv → lü）是對著一個現實中不存在的表形在測——測試永遠綠，prod 永遠打不到。

防復發：機械化守衛

新增 tests/Feature/MutationAllowedFieldsSchemaDriftTest.php，掛 RefreshDatabase 讓 schema 真的來自 database/migrations（同 VariantReplaceRegistryDriftTest 的理由：不掛的話 Schema 只看得到測試自己建的合成表，守衛永遠假綠），逐一比對全部人物子資源 handler 的 allowedFields() ＋ keyColumns()。

BIOG_TEXT_DATA 那兩欄就是它抓出來的——寫完守衛第一次跑就紅。

邊界（已寫進類註解）：它抓的是「白名單列了 migration 沒有的欄」，抓不到反向的「prod 有、migration 沒有」——那需要對 live schema 比對，不在單元測試能及的範圍。表不在 migration 裡的 handler 會被略過並記錄，不判紅。

連帶改動

• PinyinUmlaut::ALTNAME_PINYIN_V_FIELDS 移除，兩個 altname handler 不再呼叫 normalizeFields()。刻意不留空常數——留著會讓下一個人以為「只是暫時沒有欄位」而重新填進去；原地留了說明註解。
• Tier 2 完全不受影響：ALTNAME 唯一的別名羅馬字欄 c_alt_name 照舊走前端互動確認、後端不轉。原本測 Tier 1 的兩支測試改成釘住這件事，另各加一支「送幻影欄必須是 422 而非 500」。
• VariantReplaceScope::EXCLUDED_COLUMNS['ALTNAME_DATA'] 從 4 欄縮為 ['c_alt_name']（拉丁人名欄計數 13 → 10）。該處與 docs/CHAR_VARIANT_MAP_TEXT_COLUMN_ROLLOUT_PLAN.md:284 都把這四欄記成「prod-only」，是寫反的，一併更正——後者自己記下的線索（「只在合成測試表出現」「結構式掃描碰不到它」）其實正指向真正的結論。
• 文件：API.md（altnames／texts 白名單與 v → ü 說明）、PINYIN_SAVE_NORMALIZE_DESIGN.md（開頭加修訂註記＋逐處標註）、PINYIN_V_TO_UMLAUT_MIGRATION.md／.en.md、CHANGELOG.md。UnicodeNfc 類註解裡舉例用的欄名也順手改對。

刻意沒動：docs/CHAR_VARIANT_MAP_CONSOLIDATION_PLAN.md（.en）§132 提到「現行已在這兩個方法內對 c_alt_name_pinyin 等欄位做正規化」——那是已完成計畫對當時程式碼的描述，屬歷史紀錄，改它等於竄改當初的判斷依據。

驗證

• ./vendor/bin/phpunit 全量 2988 tests / 15787 assertions 綠
• ./vendor/bin/php-cs-fixer fix 全庫 0 fixed
• 無前端改動

相依

與 #1283 互不相依，皆從 upstream/develop（2adc213f）出發，可各自合併。