Implement table-driven draw rules and pity state

[ToumanLin]

Problem

The draw catalog exposes the available banners, but the server does not implement their actual probability, pity, target-rate, calibration, and inherited-pity rules. This causes character, weapon, Fate, Uniframe, and CUB results to diverge from the rules described by the client tables. The existing counters also track lifetime activity progress, so they cannot safely represent the current pity round.

Summary

• Read base probabilities and eligible rewards from authoritative client draw tables.
• Add table-driven server rules for pity thresholds, target rates, calibration, and pity inheritance.
• Implement normal character, Fate, weapon, Uniframe, and CUB behavior.
• Sample each Fate guarantee inclusively from 80 to 100 pulls.
• Apply weapon and Arrival calibration after an off-target highest-rarity result.
• Preserve the Member banner's initial 40-pull guarantee and later 60-pull guarantees.
• Persist current-round misses, sampled limits, and calibration separately from lifetime task/activity counters.
• Add focused coverage for probabilities, guarantees, calibration, targets, and inherited pity groups.

Data sources

Runtime results come from authoritative draw probability/preview tables, the server-owned draw-rule table, the selected banner, persisted player pity state, and runtime random sampling. Captured response snapshots are not used as runtime sources.

Testing

• dotnet build AscNet/AscNet.csproj
• dotnet run --project AscNet.Test/AscNet.Test.csproj -- --draw-rules-only

[reiserFSs]

Reviewed against fbd35e09c531e53ae351490f713d971c7000ea49. Request changes before merge.

The project builds and --draw-rules-only passes locally. The following gaps are not covered by that suite:

1. Per-banner target rates are replaced by group-wide 100% rates. DrawServerRule.tsv sets groups 16/22 to 100%, while existing DrawAimProbability data has 80% for banners 4001/7002 and 100% for 7069. Please reconcile the individual banner rules and add deterministic off-target/target coverage. This is an unresolved parity issue in the new rule implementation, not a claim that the previous implementation already handled these rates correctly.
2. The implemented Fate distribution does not preserve the advertised overall rate. NextLimit samples uniformly from 80 through 100. With a 1.5% base rate, that gives approximately 2.020687% overall S-rate; the normal 0.5%/60-pity rule gives approximately 1.925009%. The client rules say these overall rates are equal. The calculation is 1 / E[min(geometric(baseRate), pityLimit)]; it is an analysis of this implementation, not a retail measurement. Please establish the intended threshold distribution and test the combined rate. The current simulation resets misses and therefore tests only the base rate.
3. Initial sampled pity is not durably initialized by catalog reads. BuildDrawInfo calls GetPityRound, which adds a sampled round to player state, but DrawGetDrawInfoListRequestHandler does not save that mutation. A reconnect before a later saving operation can resample the initial limit. Please establish a durable initialization boundary and cover reload behavior rather than only serializing an already-mutated in-memory object.

GitHub currently reports conflicts, although a local Git 2.49 merge-tree calculation at the reviewed base/head was clean; please reconcile the remote merge status. No published CI checks were reported. No changes were pushed during review.