hash_ip() ignores its salt argument -- click analytics leak an unsalted hash of the raw IP

This project's whole privacy story for click analytics is: we hash IPs, we don't store them raw, salted with the app's secret so the hash can't be reverse-engineered against a rainbow table of common IPs. Right now that story is false. Anyone who can read ClickEvent.ip_hash values (a DB backup, a support engineer, an attacker with read access) can precompute sha256(ip) for every IPv4 address in a target's ISP range -- a fully tractable offline table -- and de-anonymize every click in the table, across every deployment of this app, since the hash never depends on which app/secret produced it.

hash_ip(ip_address, salt) accepts salt as a parameter but never uses it -- the function computes hashlib.sha256(ip_address.encode("utf-8")).hexdigest() and ignores salt entirely.

1. python3 -c "from app.utils.security import hash_ip; print(hash_ip('203.0.113.7', salt='secret-A')); print(hash_ip('203.0.113.7', salt='secret-B'))"
2. Observe: both lines print the identical hash.

A keyless hash of a small-entropy input (IPv4 space is ~4.3 billion values, and real traffic clusters into much smaller known ranges) is reversible by brute force in seconds. The entire point of keying/salting a hash with a per-deployment secret is that the attacker now needs the secret too -- without it, "hashed" buys nothing beyond casual obfuscation. This is a one-line fix but exactly the kind of one-line mistake that silently defeats an entire security control.

Look at how salt is currently threaded into the hash computation (it is not). Combine salt and ip_address before hashing -- the exact combination scheme does not matter much (concatenation with a separator is fine) as long as changing salt changes the output for the same IP, and the function stays deterministic for the same (ip_address, salt) pair.