[BUG] [SECURITY] Client-side security validation patterns exposed via console.warn in production

[nyxsky404]

Describe the bug
In client/src/validation/filterValidation.ts, four console.warn statements fire in production whenever the client-side XSS / SQL injection validator rejects an input:

```typescript
// filterValidation.ts:106
console.warn("[Security] Rejected XSS payload in filter input");

// filterValidation.ts:144
console.warn("[Security] Rejected XSS payload in search input");

// filterValidation.ts:153
console.warn("[Security] Rejected SQL injection pattern in search input");

// filterValidation.ts:161
console.warn("[Security] Rejected disallowed characters in search input");
```

Any user who opens browser DevTools can submit test payloads and read exactly which security control triggered — "XSS", "SQL injection", or "disallowed characters". This confirms which validation rules are active and reveals the category of pattern that was matched, allowing an attacker to methodically probe for bypasses without guessing what validation is in place.

To Reproduce

1. Open the application in a browser
2. Open DevTools → Console
3. Type <script> into any search or filter input
4. Observe: [Security] Rejected XSS payload in search input logged to the console

Expected behavior
Security event logging should be suppressed in production builds. The onRejected callback parameter already exists in validateSearchInput for surfacing user-facing feedback — the internal console.warn calls are not needed for that purpose.

Suggested fix:
```typescript
// Option A — gate on NODE_ENV (requires vite define or env var)
if (import.meta.env.DEV) {
console.warn("[Security] Rejected XSS payload in filter input");
}

// Option B — remove entirely and rely on the onRejected callback for UX feedback
```

Screenshots
N/A

Desktop (please complete the following information):

• OS: Any
• Browser: Any (DevTools required)

Additional context

• Affected file: client/src/validation/filterValidation.ts, lines 106, 144, 153, 161
• The onRejected callback in validateSearchInput (line 128) is already the correct pattern for user-facing rejection feedback — the console.warn calls are redundant in production