fix: 修復 partner 偵測時序 bug（AddOn 從未生效）+ IG meta_key 錯配

TMDO_Infocards::register() 舊版在 bootstrap 當下以 class_exists('TMEETIC_*')
偵測 partner，失敗即 early return。但本 AddOn bootstrap 掛在 plugins_loaded:6，
而 2meet-infocards 要到 :20（tmeetic_run）才 require 自身類別——在 :6 當下
TMEETIC_* 一律不存在，偵測必定失敗，兩個註冊 hook 從未被掛上，整個 AddOn
等同未啟用。

三處修法：
1. 偵測從 bootstrap 移進 hook callback 內執行，hook 一律先掛上
2. 偵測改以 TMEETIC_VERSION / TMEETIC_PLUGIN_DIR 常數優先（檔案解析當下即
   define，早於 plugins_loaded），class_exists() 退為後備
3. bootstrap priority 6 → 3；wpdo_register_custom_tables callback prio 設 5，
   讓本 AddOn 較豐富的定義勝過主外掛無 expected_columns 的版本

同時修正 IG token 兩個欄位的 meta_key 錯配（tmeetic_ig_access_token_enc /
tmeetic_ig_token_expiry），以及 registry 索引 config key expected_indexes →
indexes。

實測驗證：
- wpdo_register_fields 掛載 prio 10、wpdo_register_custom_tables prio 5
- 2meet_vendor_profiles 由本 AddOn 註冊（16 欄位 / 1 索引 / doctor_callback）
- 缺 expected_columns 由 26/29 降為 0/46
- wp wpdo doctor 60 OK / 0 FAIL；anti-EAV lint 通過；站台 200/200

CHANGELOG.md

@@ -13,6 +13,60 @@ Versioning follows [Semantic Versioning](https://semver.org/).
 
 ---
 
+## [0.1.1] — 2026-08-08 — 修復 partner 偵測時序 bug（AddOn 從未生效）與 IG 欄位 meta_key 錯配
+
+### Fixed
+
+- **本 AddOn 從未掛上任何 hook，等同未啟用（嚴重）。** `TMDO_Infocards::register()`
+  舊版在 bootstrap 當下就以 `class_exists( 'TMEETIC_*' )` 偵測 partner，失敗即
+  early return。但本 AddOn bootstrap 掛在 `plugins_loaded:6`，而 2meet-infocards
+  要到 `plugins_loaded:20`（`tmeetic_run`）才 require 自身類別——在 :6 當下
+  TMEETIC_* 類別一律不存在，偵測**必定**失敗，於是 `wpdo_register_fields` /
+  `wpdo_register_custom_tables` 兩個 hook 從未被掛上（實測：`TMEETIC_Frontend`
+  在 prio 6 = MISSING、prio 21 = EXISTS）。三處修法：
+  1. 偵測從 bootstrap 移進 hook callback 內執行（`register_post_fields()` /
+     `register_custom_tables()` 開頭），hook 一律先掛上。核心於
+     `plugins_loaded:30` 有 late-bind safety net 會重新 fire 註冊 hook，唯有把
+     偵測延後到 callback 執行當下才會正確生效。
+  2. 偵測改以 `TMEETIC_VERSION` / `TMEETIC_PLUGIN_DIR` 常數優先，`class_exists()`
+     退為後備。這兩個常數在 `2meet-infocards.php` 的**檔案解析當下**即 define，
+     早於 `plugins_loaded`；核心 `fire_registration()` 最早在 `plugins_loaded:4`
+     觸發，該時點只有常數可用，只靠 `class_exists()` 會在最關鍵的第一次註冊誤判
+     為「partner 不存在」。
+  3. bootstrap priority 由 6 提前到 3，`wpdo_register_custom_tables` callback
+     priority 設為 5。理由有二：核心 `fire_registration()` 最早在
+     `plugins_loaded:4` 觸發，掛在 :6 必定錯過第一次註冊；且
+     `TMDO_Custom_Table_Registry` 對同一 `provider:table_name` 是「先註冊者勝、
+     後者回傳 false」，主外掛 2meet-infocards 的 closure 在檔案解析當下就掛上
+     prio 10，若不提前，會先以無 `expected_columns` 的版本佔走 key。
+- IG token 兩個欄位註冊的 meta_key 與 2meet-infocards 程式碼實際讀寫的 key 不符，
+  導致它們從未真正進入 TMDO 加速路徑（仍落回 `wp_postmeta`）：
+  - `tmeetic_ig_token_enc` → `tmeetic_ig_access_token_enc`
+  - `tmeetic_ig_token_expires_at` → `tmeetic_ig_token_expiry`
+- `TMDO_Custom_Table_Registry::register()` 的索引期望值 config key 由
+  `expected_indexes` 更正為 `indexes`。該 API 以 `wp_parse_args()` 併入預設值，
+  未知 key 會被**靜默丟棄**——先前索引期望值等同從未送達 registry，
+  `wp wpdo doctor` 的 schema drift 只驗欄位、不驗索引。此問題橫跨全部 8 個 AddOn，
+  已一併更正。
+
+### Added
+
+- 註冊先前完全未註冊的兩個 `hp_vendor` Cold zone 欄位：`tmeetic_ig_username`、
+  `tmeetic_ig_feed_show`。
+- 為 `2meet_vendor_profiles`（16 欄）/ `2meet_cards`（25 欄）/
+  `2meet_theme_styles`（8 欄）三張表補上 `expected_columns` 與 `indexes`，
+  `wp wpdo doctor` 才能對它們做 schema drift 檢查。先前只註冊表名，doctor
+  無從判斷欄位或索引是否漂移。
+
+### Removed
+
+- 移除 `tmeetic_ig_app_id`、`tmeetic_ig_app_secret_enc` 兩個幽靈註冊。IG 應用
+  憑證是**站台層級**設定，實際存於 `wp_options` 的 `2meetic_ig_app_id` /
+  `2meetic_ig_app_secret_enc`，並非 `hp_vendor` postmeta；全外掛對這兩個
+  postmeta key 零讀寫，註冊只會在 Cold zone 留下永遠空的欄位定義。
+
+---
+
 ## [0.1.0] — TBD
 
 ### Added (initial release, scaffold)