fix: recalibrate find({ limit }) cap + two-tier enforcement + caller location

Brainy 7.30.0 introduced a memory-derived synchronous cap on `find({ limit })`
to prevent OOM. The cap was sound in intent but ~4x too conservative in
calibration: assumed 100 KB per result while typical entity footprint is 7-10 KB
(384-dim float32 vector ≈ 1.5 KB + standard fields + metadata). On a 900 MB
free-memory box the cap derived to 9000 — breaking common safety-cap patterns
like `find({ type, where, limit: 10_000 })` that typically return 10-500
entities. Surfaced as a runtime regression with cascading 500s degrading
production dashboards.

Three concurrent fixes:

A. RECALIBRATE THE FORMULA
- src/utils/paramValidation.ts:175,196,212 — the three memory-derived priorities
  (reservedQueryMemory / containerMemory / freeMemory) all divided by
  100 * 1024 * 1024 (100 KB per result, ~10-15x over conservative). Replaced
  with a new MAX_LIMIT_KB_PER_RESULT = 25 constant that matches observed
  entity size.
- Result: 4 GB container cap goes 10_000 → 40_000; 2 GB cap goes 5_000 →
  20_000; 900 MB free-memory cap goes 9_000 → ~36_000. 100k hard ceiling
  unchanged. `maxQueryLimit` / `reservedQueryMemory` constructor overrides
  unchanged in behavior.

B. TWO-TIER ENFORCEMENT (warn-then-throw)
- Below cap (limit <= maxLimit): silent pass, unchanged.
- Soft tier (maxLimit < limit <= 2 * maxLimit): NEW — one-time warning per
  call site (dedup keyed on caller stack frame + limit value), query
  proceeds. Pre-7.30.2 code that relied on the cap silently allowing typical
  safety-cap limits keeps working; the warning teaches the recipe so consumers
  can fix it intentionally.
- Hard tier (limit > 2 * maxLimit): throw with the same teaching message
  format. Real OOM territory; the cap stops being a recommendation and becomes
  a guardrail.
- The 2x soft margin absorbs typical safety-cap patterns (limit: 10_000
  against a 9 K-cap box) without disabling OOM protection. Real OOM territory
  on a JS in-memory brain is hundreds of thousands of results, not 10x the
  safety cap.

C. IMPROVED ERROR / WARNING MESSAGE
- Same shape as the 7.30.1 enforcement-error messages: state the problem,
  name the three escape valves (maxQueryLimit / reservedQueryMemory /
  pagination), include caller location, link to docs.
- Extracted findCallerLocation() helper from brainy.ts to a new
  src/utils/callerLocation.ts so both the subtype enforcement (7.30.1) and
  the limit enforcement (7.30.2) share one implementation without circular
  imports.

DOCS
- New docs/guides/find-limits.md (public: true) — full reference: why the cap
  exists, the four memory sources the auto-config considers, the three escape
  valves with when-to-use-which guidance, and an explicit "pagination is the
  future-proof pattern" callout (8.0 may tighten the cap further; pagination
  keeps working unchanged).
- docs/api/README.md find() entry gets a one-paragraph `limit` tip + pointer
  to the new guide.
- RELEASES.md v7.30.2 entry.

TESTS
- New tests/integration/find-limits.test.ts (9 tests): below-cap silent pass;
  soft-tier warns once per call site (dedup verified by exercising same vs.
  different source lines via wrapper closures); soft-tier message format
  (names all three escape valves + docs link); soft-tier message includes
  caller location; hard-tier throws; hard-tier message format same as
  soft-tier; consumer maxQueryLimit override raises the cap and shifts both
  tiers accordingly; pre-7.30.2 regression scenario explicitly covered.
- tests/unit/utils/memoryLimits.test.ts — 4 tests updated for the recalibrated
  cap values (hardcoded expected numbers bumped 4x to match new 25 KB/result
  assumption).
- tests/unit/utils/paramValidation.test.ts — auto-limit test extended to cover
  the three-tier semantics (below-cap pass / soft-tier silent / hard-tier
  throw).
- Existing suites unchanged: subtype-and-facets 26/26, verb-subtype-and-
  enforcement 30/30, strict-mode-self-test 13/13. Unit 1468/1468.

CORTEX COMPATIBILITY
- Zero Cortex changes required. Every change is JS-side: formula recalibration
  runs in ValidationConfig.constructor(), two-tier enforcement runs in
  validateFindParams(), both fire before any storage / index / Cortex call.
- The new guide notes that Brainy 8.0's Datomic-style Db.find() may tighten
  per-call limits to keep snapshot semantics cheap; pagination remains the
  pattern that's guaranteed to keep working.

REPO-WIDE CLEANUP
Brainy is the only Soulcraft project that is open source. This commit also
scrubs closed-source product names and product-specific class/field references
from every tracked file in the repo (src/, docs/, tests/, RELEASES.md,
CHANGELOG.md). Consumer-reported bugs, regression scenarios, and release
notes now refer to "a consumer", "a downstream application", "a production
deployment", or "an internal report" — never to the named product. Two
product-named test files renamed to neutral diagnostic names. CLAUDE.md gains
a project-level guard rule documenting the policy and an example list of the
identifiers that may not appear in tracked code.

Verification
- npx tsc --noEmit: clean
- npm test: 1468 / 1468 unit
- All four integration subtype + verb + strict + find-limits suites: 78/78
- npm run build: clean
- Closed-source product reference audit: clean

tests/unit/utils/memoryLimits.test.ts

@@ -98,9 +98,10 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
 
       const config = ValidationConfig.getInstance()
 
-      // 4GB * 0.25 = 1GB for queries
-      // 1GB / 100MB = 10 units * 1000 = 10,000 limit
-      expect(config.maxLimit).toBe(10000)
+      // 4 GB × 0.25 = 1 GB for queries; at 25 KB / result (7.30.2 calibration)
+      // → 1 GB / 25 KB = ~40_960 → floor to 40 × 1000 = 40_000.
+      // Pre-7.30.2 used 100 KB / result and returned 10_000 here.
+      expect(config.maxLimit).toBe(40000)
     })
 
     it('should respect absolute maximum of 100k', () => {
@@ -134,12 +135,14 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
     })
 
     it('should respect reservedQueryMemory override', () => {
-      // Reserve 1GB for queries
+      // Reserve 1 GB for queries; at 25 KB / result (7.30.2) → 1 GB / 25 KB
+      // = ~40_960 → floor to 40 × 1000 = 40_000. Pre-7.30.2 used 100 KB /
+      // result and this returned 10_000.
       const config = ValidationConfig.getInstance({
         reservedQueryMemory: 1 * 1024 * 1024 * 1024
       })
 
-      expect(config.maxLimit).toBe(10000) // 1GB / 100MB * 1000
+      expect(config.maxLimit).toBe(40000)
       expect(config.limitBasis).toBe('reservedMemory')
     })
 
@@ -213,7 +216,7 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
     it('should configure reserved memory via Brain constructor', async () => {
       const brain = new Brainy({
         storage: { type: 'memory' },
-        reservedQueryMemory: 500 * 1024 * 1024, // 500MB
+        reservedQueryMemory: 500 * 1024 * 1024, // 500 MB
         silent: true
       })
 
@@ -221,8 +224,9 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
 
       const stats = brain.getMemoryStats()
 
-      // 500MB / 100MB * 1000 = 5000
-      expect(stats.limits.maxQueryLimit).toBe(5000)
+      // 500 MB / 25 KB per result (7.30.2 calibration) = ~20_000.
+      // Pre-7.30.2 used 100 KB / result and this returned 5000.
+      expect(stats.limits.maxQueryLimit).toBe(20000)
       expect(stats.limits.basis).toBe('reservedMemory')
       expect(stats.config.reservedQueryMemory).toBe(500 * 1024 * 1024)
 
@@ -243,8 +247,10 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
 
       expect(stats.memory.containerLimit).toBe(2 * 1024 * 1024 * 1024)
       expect(stats.limits.basis).toBe('containerMemory')
-      // 2GB * 0.25 = 500MB -> 5000 limit
-      expect(stats.limits.maxQueryLimit).toBe(5000)
+      // 2 GB × 0.25 = 512 MB query budget; at 25 KB per result (7.30.2) →
+      // 512 MB / 25 KB = ~20_971 → floor to 20 × 1000 = 20_000. Pre-7.30.2
+      // used 100 KB per result and this returned 5_000.
+      expect(stats.limits.maxQueryLimit).toBe(20000)
 
       await brain.close()
     })
@@ -341,9 +347,11 @@ describe('Memory Limits - Container Detection & Smart Calculation', () => {
 
       const stats = brain.getMemoryStats()
 
-      // Should allocate 1GB (25% of 4GB) for queries
+      // Allocates 1 GB (25% of 4 GB) for queries; at 25 KB per result
+      // (7.30.2 calibration) → 1 GB / 25 KB = ~40_960 → floor to 40 × 1000 =
+      // 40_000. Pre-7.30.2 used 100 KB per result and this returned 10_000.
       expect(stats.memory.containerLimit).toBe(4 * 1024 * 1024 * 1024)
-      expect(stats.limits.maxQueryLimit).toBe(10000)
+      expect(stats.limits.maxQueryLimit).toBe(40000)
       expect(stats.limits.basis).toBe('containerMemory')
 
       await brain.close()

tests/unit/utils/paramValidation.test.ts

@@ -93,18 +93,27 @@ describe('Zero-Config Parameter Validation', () => {
       })).toThrow('invalid NounType: InvalidType')
     })
     
-    it('should auto-limit based on system memory', () => {
+    it('should auto-limit based on system memory (two-tier enforcement)', () => {
       const config = getValidationConfig()
-      
-      // Should reject limits above auto-configured max
+
+      // 7.30.2+ design: the cap fires in two tiers.
+      // - Below cap (`limit <= maxLimit`): silent pass, no signal.
+      // - Soft tier (`maxLimit < limit <= 2 * maxLimit`): one-time warning
+      //   per call site, query proceeds. No throw.
+      // - Hard tier (`limit > 2 * maxLimit`): real OOM danger zone, throw.
+
+      // Below cap → pass
+      expect(() => validateFindParams({ limit: config.maxLimit })).not.toThrow()
+
+      // Soft tier → no throw (just a warn we don't assert here — proper coverage
+      // lives in the find-limits integration suite which can intercept the log).
+      expect(() => validateFindParams({ limit: config.maxLimit + 1 })).not.toThrow()
+      expect(() => validateFindParams({ limit: config.maxLimit * 2 })).not.toThrow()
+
+      // Hard tier → throw with the new message format
       expect(() => validateFindParams({
-        limit: config.maxLimit + 1
-      })).toThrow(`limit exceeds auto-configured maximum of ${config.maxLimit}`)
-      
-      // Should accept limits at or below max
-      expect(() => validateFindParams({
-        limit: config.maxLimit
-      })).not.toThrow()
+        limit: config.maxLimit * 2 + 1
+      })).toThrow(/exceeds the auto-configured query limit/)
     })
     
     it('should auto-limit query length', () => {