SCRUM-1067-A PII refusal names the override entry that would clear it

[emnarahmouni-exmergo]

Closes : #217
The query firewall's PII refusal offered only two routes (aggregate or drop the column); the third route, a reviewed pii_overrides entry, existed and was never mentioned, so in practice callers opened a raw SQL client instead, where neither the firewall nor the PII policy applies.
The refusal now names, for each blocking column, the exact pii_overrides entry that would clear it, in flow-mapping YAML ready to paste into .dex/config.yml: the fully-qualified exact form always, plus a scope-glob pattern form when the same column name is flagged at the same category on another dataset.
The suggested scope is never wider than the schema that evidence came from (the dataset's own identifier with the table segment wildcarded); a caller who knows it reaches further widens the glob themselves.
Widened the internal _Taint type in guards/query_firewall.py from (label, confidence) to carry the fully-qualified identifier, column name, and category too, since the short table name in the display label alone isn't enough to build a safe, unambiguous override (two datasets can share a short name).
The suggestion is text in the message only, built from column identity (dataset, column, category) alone, the same structural guarantee PIIFlag itself makes, so no value can appear in it by construction. Nothing is applied automatically.
Answered the issue's open question (suppress for high-severity categories?) as no, documented in the CHANGELOG: nothing in the engine ranks PIICategory by severity today, the block threshold is deliberately uniform, and the suggestion is inert text a human must still copy/edit/commit regardless of category.

Before the fix:

After :

[marcociav-exmergo]

LGTM! Thanks for this @emnarahmouni-exmergo, I actually had this issue a few days ago