Guild (Ryoudan) Ticket shop — entire subsystem unimplemented

[Houmgaor]

Summary

Players have reported that "guild tickets" are no longer usable/purchasable
anywhere. Investigation shows this isn't a regression — the whole subsystem
was never implemented in Erupe.

In plain terms: guild members earn a "Ryoudan Ticket" item by playing Diva
Defense (interception quests), then spend it at a shop screen that turns out
to be physically anchored at the guild's dinner table — which is why players
describe it as tied to clan cooking (cuisine de clan). See the sections
below for how each part was confirmed.

What the ticket actually is (confirmed via Wii U ground-truth decompilation)

Item 1026 (猟団チケット / Ryoudan Ticket) is spent as currency in a
dedicated shop screen. Decompiling lb_ticket_getItem in the Wii U build
(MHF G Z2 v2064, real debug symbols, not guessed names) shows:

Lb_itemUse_expage(0x402, iVar5);   // 0x402 == 1026 == Ryoudan Ticket
...
MhfItem_buyItem(uVar1, *(undefined4 *)(param_1 + 0x60), -iVar5);

iVar5 is a price computed from a per-context price table
(lb_shop_get_ticket_price_id, Lb_get_itemPrice) and uVar1 is the item ID
read from a shop catalog buffer populated by lb_shop_ticketPageInit.

Tickets themselves are earned via Diva Defense (interception) play —
Lb_get_ryoudan_ticket sums Ud_item_num_ck + Ud_stock_item_num_ck3 +
Ud_stock_item_num_ck3_expage (all UD/interception stock counters).

Why the shop is associated with cooking (not a mistranslation)

lb_shop_ticketPageInit's price/catalog lookup reuses the same three
"where is the player standing" values (0xca / 0xcb / 0xcc) as
lb_ryoudan_dinner_table_find_entry_id_by_stage — the function that detects
whether the player is standing next to the guild room's dinner table. Sharing
those values means the ticket shop can only be opened from that same
location, i.e. the shop UI is triggered at the dinner table. That's the
mechanical reason players associate "guild tickets" with clan cooking, even
though spending them doesn't involve cooking mechanics itself.

What's missing server-side

• No handler consumes item 1026 to grant a real item — handleMsgMhfUseUdShopCoin
  is a documented stub (docs/unimplemented.md).
• server/channelserver/handlers_guild_cooking.go (the guild dinner/meal
  registration system) has no ticket-shop-adjacent logic at all.
• The actual catalog contents (which items are purchasable, at what ticket
  price) live in a data structure (SHOP_TBL_DATA2) that hasn't been mapped
  yet — lb_shop_tbl_data_get is a large multi-branch dispatcher shared by
  many unrelated shop screens, and the ticket-shop-specific branch/data still
  needs isolating.

Next steps

These are three separable tasks, not one:

1. Map the SHOP_TBL_DATA2 structure and isolate the ticket-shop-specific
   catalog entries (item IDs + ticket prices). Pure RE work.
2. Implement handleMsgMhfUseUdShopCoin (or whatever the real ticket-spend
   packet turns out to be) against that catalog. Depends on (1).
3. Decide whether/how to expose this via the existing shop_items table
   (a new shop_type?) or a dedicated table. A schema/architecture call that
   doesn't strictly depend on (1) or (2).