Fix SIGSEGV in CFileNameManager caused by stale share data pointer across test suites

[Copilot]

CSakuraEnvironmentTest.ExpandParameter_mixed crashed with SIGSEGV in CFileNameManager::GetTransformFileNameFast in the mingw (Debug) CI job. CFileNameManager is a TSingleton that cached m_pShareData = &GetDllShareData() in its constructor. In the test environment, CShareData is destroyed and recreated between test suites — when TrayWndTest ran before CSakuraEnvironmentTest, the singleton's cached pointer referred to unmapped memory.

Fix

CFileNameManager.h / CFileNameManager.cpp: Remove m_pShareData member. Replace all m_pShareData-> accesses with direct GetDllShareData() calls at each use site.

// Before: cached in constructor, stale after share data recreation
CFileNameManager() {
    m_pShareData = &GetDllShareData();  // ← stale after TearDownShareData()
    m_nTransformFileNameCount = -1;
}

// After: resolve on every call
if( GetDllShareData().m_Common.m_sFileName.m_bTransformShortPath && cchMaxWidth != -1 ){

This is safe in production because CShareData lives for the entire process lifetime; it only matters in tests where share data is cycled.

Also included

Merge of feature/improve_traywnd_test which introduced the TrayWndTest tests that exposed this bug, along with several SonarQube fixes in CControlTray.cpp/.h and test infrastructure updates (ShareDataTestSuite, EditorTestSuite, UiaTestSuite).

[berryzplus]

解析結果は正しいのだけど、直し方が元の設計に沿ってないようなので却下です。

仕様
CFileNameManager は生成した時点の共有メモリポインタをキャッシュして使う。
m_pShareDataは生成時以外変更しないため、使用時にはNULLチェックをしない。

共有メモリの生成状態に左右されるコードでありながら、
共有メモリの生成状態を考慮してないため、
オブジェクトの生存期間を「共有メモリの生成後、破棄される前まで」に限定してやる必要あり。

そうしないとあちこち変更する感じになり、できるだけ元コードを変更しない、の方針に反してしまう。

[berryzplus]

「このクラスがシングルトンであること」が誤り。

前提

シングルトンクラスは、状態を持ってはならない。

いつ生成しても不変なオブジェクトを何度も生成しないための仕組みがシングルトン。

2つ以上の状態を持つオブジェクトをシングルトンにしてはならない。
TSingleton テンプレート利用クラスのほとんどがこれにあたるので、本当は直さないといけない。

この修正の趣旨

状態変数 m_pShareData の代わりに GetDllShareDataPtr() を使う。

ダメ出しポイント

もともと、状態変数 m_pShareData は絶対 NULL にならない。
したがって、m_pShareData が NULL だった場合のガードは存在しない。

GetDllShareData() は NULL を返し得る関数 として定義している。
この関数の戻り値は deref する前にNULLチェックする必要がある。

つまり、こうなる。

仕様上NULLにならないからチェックしてないコード。
　↓
仕様上NULLになり得るけど移行した結果チェックが漏れたコード。

[berryzplus]

この修正 a01decc を入れて対応したのでクローズ。