feat: 設定・状態を永続化する多層レジストリ機能（ユーザー設定・検索履歴・テーブルソート状態 等）

[shogun-aki-tweak]

目的

ユーザー設定・UI 状態・履歴などを永続化する汎用レジストリを導入する。現状こうした「設定・状態」は個別に保存機構を作る必要があり散在しがち。スコープ付きの永続キー・バリュー・ストアを 1 つ用意し、一貫した保存・解決・共有を提供する。

永続化したいものの例

• ユーザー設定（例: feat(backend): ユーザーの居住国固有の設定を追加する #367 の居住国固有の設定）
• 検索履歴
• テーブルのソート状態（一覧テーブルの並び順・ソート列/方向）
• その他、ユーザー / UI ごとの設定・状態

設計方針

多層スコープ（OS のレジストリ流・一般 → 具体で上書き）

コード既定（安全な既定値）
 → system / instance（全体既定）
   → tenant（テナント上書き）
     → project（プロジェクト上書き）
       → user（個人・最優先）

• キー単位のスパース上書き：各層は触るキーだけ持ち、未設定キーは一つ上（一般）の層へ fall through。
• 有効値 ＝ キー単位の deep-merge（オブジェクト丸ごと置換でなく per-key で most-specific-wins）。
• ロック（任意）：上位層（管理者）が設定を enforced にでき、下位層の上書きを禁止（統制が要る設定向け）。
• 純粋な個人設定（検索履歴・テーブルソート状態 等）は user 層のみを使う特例として自然に収まる。

永続・共有

• backend（SeaORM）に scope 別のスパース上書き表（system / tenant_id / project_id / user_id → 上書きキー集合 ＋ lock フラグ）。
• SSR が権威：有効値を層解決し、pageContext 経由で client と一致させる（＝共有）。頻繁に変わる個人状態（検索履歴等）はクライアント側の楽観更新も併用可。

安全境界

• レジストリが持つのは**設定値（データ）**のみ。任意コード・任意 HTML は持たせない。各キーは型 / スキーマで検証し、不正値は既定へフォールバック。テナント編集可にする場合も、値の型・範囲を allowlist で縛る。

拡張性

• 新しい設定キーはキーごとの型定義を足すだけで追加できる設計にする（大きなスキーマ変更なしに項目を増やせる）。将来、任意の機能が「自分の設定名前空間」を registry に持てる形が望ましい。

段階

• Phase 1：user 層 ＋ コード既定だけの最小構成で、まず検索履歴 / テーブルソート状態 / feat(backend): ユーザーの居住国固有の設定を追加する #367 のような user 設定を永続化。
• Phase 2：tenant / project 層・ロック・SSR 層解決の共有まで拡張。

関連

• feat(backend): ユーザーの居住国固有の設定を追加する #367（ユーザーの居住国固有の設定）＝本レジストリの消費者の一例