[stantheman0128]

Closes #906.

Problem

STCharacters.txt currently maps simplified 雇 to a single traditional candidate:

雇	僱

Issue #906 asks to keep 僱 as the default and add 雇 as a non-default candidate (雇 僱 雇). 《重編國語辭典修訂本》 lists forms such as 雇員 with 雇, so both traditional forms should remain available. Employment phrases already pin the 僱 reading in STPhrases.txt (雇员 / 雇主 / 解雇 / ...). Collaborator frankslin also noted that surname uses of 雇 are awkward when only 僱 exists as a candidate.

Change

• STCharacters.txt: 雇 僱 -> 雇 僱 雇 (default stays 僱; 雇 kept as non-default candidate, same multi-candidate style as 丑 醜 丑 / 雕 雕 鵰)
• test/testcases/testcases.json: add BYVoid_OpenCC_Issue_906_* covering default 雇 / employment phrases under s2t / s2tw / s2twp / s2hk, plus t2s round-trip for 僱員

No STPhrases.txt edits. Existing phrase entries already force the employment reading.

Verification

I had no C++ toolchain available, so I verified with the OpenCC 1.4.1 wheel engine driving this branch's text dictionaries directly: config JSONs identical to data/config/*.json with ocd2 references switched to text. There are no conversion related engine changes between ver.1.4.1 and master for this character mapping. A/B against packaged wheel dictionaries with the same harness:

STCharacters line on branch:                    雇<TAB>僱 雇
new Issue_906 cases on this branch:             PASS
  s2t: 雇、雇佣、雇员、雇主、解雇、聘雇、劳雇关系
    -> 僱、僱傭、僱員、僱主、解僱、聘僱、勞僱關係
  t2s: 僱員 -> 雇员
existing s2t expectations A/B (exclude #906):   92 same / 0 diff
sort.py on STCharacters.txt:                    mapping remains 雇<TAB>僱 雇

Default convert behavior is unchanged (first candidate is still 僱). The point of the change is the explicit non-default 雇 candidate requested in #906.

Please treat the CI Bazel dictionary tests as the authoritative check.

This fix was developed with AI assistance (Cursor/Grok) and verified locally as shown above.