fix: filter physics volumes like the client's collision groups

Volumes on the server touched far more than in the client:

- An enemy's body in the physics world was a sphere the size of its aggro
  radius, so trigger and damage volumes caught enemies from far away
  (Cavalry Hill enemies taking damage on spawn). It is now the enemy's
  own radius and collision group from its physics component.
- Trigger volumes ignored their collision group and caught everything.
  dpEntity now filters with the client's collision filter
  (PeCollisionFilter, 1.10.64 0x00fb6940, group table from 0x00fcf9a0):
  POI walls ignore enemies, threat clearing walls ignore players, and
  so on. The aggro sensor keeps seeing only players.
- Rotated boxes were tested as the axis aligned box around them, which
  for a turned wall covers a big square (the AG survival boundary).
  Sphere and point tests now use the box's own axes.

Proximity monitors take an optional collision group like live's
SetProximityRadius; the AM shield generators use live's (10 finds
enemies, 1 finds players).

Fixes #1127
Refs #1971

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dGame/dComponents/ProximityMonitorComponent.h

@@ -32,7 +32,11 @@ public:
 	 * @param proxRadius the radius to use for the physics entity we use to detect proximity
 	 * @param name the name of this check
 	 */
-	void SetProximityRadius(float proxRadius, const std::string& name);
+	/**
+	 * Adds a sphere that reports what enters and leaves it
+	 * @param collisionGroup the collision group it filters on like the client's (see dpCollisionFilter), 0 for everything
+	 */
+	void SetProximityRadius(float proxRadius, const std::string& name, uint32_t collisionGroup = 0);
 
 	/**
 	 * Creates an entry to check proximity for, given a name