fix(housing): allow non-staff to place classic house pieces in customization (#2500)

## Summary

House customization rejected ~40% of components — all classic/base tiles such as **sandstone** — for non-staff players. The pieces appeared briefly in the editor, then vanished before commit; only staff (GM+) could add them.

## Root cause

A data-convention mismatch introduced when housing.bin support was added (#2329).

- The OSI `housing.bin` encodes pre-AOS base pieces with the client **T2A** feature bit (`0x1`).
- `walls.txt` (and RunUO) encode the same pieces as `FeatureMask = 0` (always valid).
- `ComponentVerification.CheckValidity` validates against `ExpansionInfo.HousingFlags`, whose enum has no `0x1` bit, so base pieces failed `(HousingFlags & 0x1) != 0`.
- `HouseFoundation.Designer_Build` only enforces `ValidPiece` for `AccessLevel < GameMaster`, so staff bypassed validation while players had placements rejected — the server re-sends the design state and the client rebuilds the house from it, erasing the just-placed piece.

This only affects servers loading `housing.bin` from a UOP client; the old txt-only path (pre-#2329, like RunUO) was unaffected because base pieces are `0` there.

## Fix

Normalize the `housing.bin` feature mask to the housing-tier bits on load (`& HousingFlags.HousingEJ`). Base pieces collapse to `0` (always valid, exactly as `walls.txt` encodes them); `AOS`/`SE`/`ML`/... pass through unchanged. Both data sources now produce an identical validity table, matching RunUO behavior. `CheckValidity` and the `val != -1` anti-cheat guard are unchanged.

## Verification

- Parsed the real `housing.bin` from a 7.0.x client: sandstone (`0x345`) loads as `0x1` → `& HousingEJ` → `0` → valid; tier pieces (`0x40` SE, etc.) pass through; unregistered tiles stay `-1` → rejected.
- Confirmed OSI's own files disagree for the same pieces: `walls.txt` base `FeatureMask = 0` vs `housing.bin` `0x1`.
- `dotnet build` clean (0 warnings, 0 errors).

Projects/UOContent/Multis/ComponentVerification.cs

@@ -13,6 +13,13 @@ public static class ComponentVerification
     private static int[] _multiTable;
     private static bool _loaded;
 
+    // housing.bin stores each component's feature mask in the client's feature-flag bit space, which
+    // tags pre-AOS base pieces (e.g. sandstone) with low bits - notably T2A (0x1) - that HousingFlags
+    // does not model. CheckValidity validates against HousingFlags, so strip everything except the
+    // housing-tier bits when loading: base pieces collapse to 0 (always valid, exactly as walls.txt
+    // encodes them) while AOS/SE/ML/... line up unchanged.
+    private const int HousingTierMask = (int)HousingFlags.HousingEJ;
+
     public static bool IsItemValid(int itemID)
     {
         EnsureLoaded();
@@ -93,7 +100,7 @@ public static class ComponentVerification
             {
                 reader.ReadUInt32LE(); // category_id
                 reader.ReadUInt32LE(); // subcategory_id
-                var featureMask = (int)reader.ReadUInt32LE();
+                var featureMask = (int)reader.ReadUInt32LE() & HousingTierMask;
                 reader.ReadUInt32LE(); // cliloc_id
 
                 // fields_1