fix(vuln-intel): use exploits_found key in threat-feeds correlation and mark simulated IP/hash results

The /api/vuln-intel/threat-feeds correlation route had two defects reported in #261:

1. Dead exploit-availability boost (key-name mismatch). CVEIntelligenceManager.search_existing_exploits() returns the count as exploits_found, but the correlation route read total_exploits — a key that is never set anywhere in hexstrike_server.py. The check was therefore always false: the exploit_availability correlation entry never appeared and the +25 threat-score boost never fired, even for CVEs with many known public exploits. The route now reads exploits_found, the producer's actual (and publicly returned) key.

2. Simulated IP/hash results were indistinguishable from real ones. IP-reputation and file-hash correlation entries are hardcoded placeholders, yet the response gave them a MEDIUM threat level with nothing marking them as simulated — downstream agents can read the fallback as real intelligence. Both entries now carry "simulated": true.

Evidence (repo has no test suite; verified with a harness that drives the real Flask route via its test client, stubbing only the two network-backed CVE methods with the producer's exact return shapes):

• Before: indicators [CVE-2024-0001, 203.0.113.7, <sha256>] with the exploit search reporting exploits_found=3 → correlation types [cve, ip_reputation, file_hash], no exploit_availability entry, threat_score 13.33, no simulated marker on the IP/hash entries.
• After: correlation types [cve, exploit_availability, ip_reputation, file_hash], exploit_availability.exploits_found = 3, threat_score 21.67 ((40 + 25) / 3), both placeholder entries carry "simulated": true.
• python -m py_compile hexstrike_server.py passes; grep total_exploits returns nothing after the change.

Fixes #261.