fix: align filtered display and harden detection prompt notation

[lipikaramaswamy]

Summary

• Fix display rendering so filtered replace runs use final_entities when present, even if the filtered set is empty, instead of falling back to _detected_entities
• Tighten detection prompt guidance around partial-token drops and technical-value classification to reduce noisy tagging
• Rename inline tag markers from PII to SENSITIVE so prompt examples and tagged text better reflect the broader privacy-sensitive scope

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring

Testing

• Tests pass locally
• Added/updated tests for changes

[andreatgretel]

src/anonymizer/engine/detection/postprocess.py:369

if needle[0].isalnum() or needle[0] == "_":
    escaped = rf"(?<![A-Za-z0-9_]){escaped}"
if needle[-1].isalnum() or needle[-1] == "_":
    escaped = rf"{escaped}(?![A-Za-z0-9_])"

I think this still matches inside hyphenated tokens, so something like internal-procID-id may get tagged again during expansion. maybe worth tightening the boundary check and adding a small regression test?

[lipikaramaswamy]

src/anonymizer/engine/detection/postprocess.py:369

if needle[0].isalnum() or needle[0] == "_":
    escaped = rf"(?<![A-Za-z0-9_]){escaped}"
if needle[-1].isalnum() or needle[-1] == "_":
    escaped = rf"{escaped}(?![A-Za-z0-9_])"

I think this still matches inside hyphenated tokens, so something like internal-procID-id may get tagged again during expansion. maybe worth tightening the boundary check and adding a small regression test?

src/anonymizer/engine/detection/postprocess.py:369

if needle[0].isalnum() or needle[0] == "_":
    escaped = rf"(?<![A-Za-z0-9_]){escaped}"
if needle[-1].isalnum() or needle[-1] == "_":
    escaped = rf"{escaped}(?![A-Za-z0-9_])"

I think this still matches inside hyphenated tokens, so something like internal-procID-id may get tagged again during expansion. maybe worth tightening the boundary check and adding a small regression test?

Thanks, @asteier2026 and I discussed this, and we will move work on hyphens to a separate PR since there are nuances depending on the type of data (#46)

[lipikaramaswamy]

I'll merge this PR, we will pick up hyphen work as part of a different PR linked to #46