fix(pr-evaluator): don't flag PostHog context tags as PII in eq_no_pii

The eq_no_pii rubric item treated any PII on an event as a violation, which
false-flagged the documented PostHog pattern: the Python `tag()` / `new_context()`
API and the Django `PosthogContextMiddleware` (which tags distinct id, session,
and the authenticated user's email by design) attach request-scoped context to
events on purpose.

Carve those out. NO is reserved for PII the integration hand-copies into an
event `properties={}` dict where a person-property method was the right call, or
PII used as a fabricated `distinct_id`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: gewenyu99

services/pr-evaluator/prompts/evaluation.md

@@ -73,5 +73,5 @@ For each item, answer YES/NO based on the changed files:
 - **eq_real_actions** — Events represent real user actions (not synthetic or meaningless events; map to actual product flows like signup, purchase, page view)
 - **eq_product_insights** — Events enable product insights (could build a funnel, trend, or retention chart from these events)
 - **eq_enriched_properties** — Events include relevant properties (events have contextual properties, not bare captures with no properties)
-- **eq_no_pii** — No PII in event properties (emails, names, phones belong in person properties, not in capture() event properties). PII should be set via person properties methods — `$set`/`$set_once` in capture calls, `setPersonProperties()` helpers, or `identify()` — so the data lives on the user profile, not on individual events. This applies across ALL SDKs (client and server).
+- **eq_no_pii** — No PII hand-placed into event properties (emails, names, phones belong on the person profile, not in a `capture()` `properties={}` dict). Set them via person-property methods — `$set`/`$set_once` in capture calls, `setPersonProperties()` helpers, or `identify()`. **Context tags are NOT a violation.** PostHog's context mechanism — the Python `tag()` / `new_context()` API and the Django `PosthogContextMiddleware`, which tags the request's distinct ID, session, and the authenticated user's **email** by design — is the SDK's intended way to attach request-scoped context to events. Do not flag `tag()` calls or the middleware's default tags (email included) as a PII leak; that is the documented pattern, not a mistake. Reserve **NO** for PII the integration explicitly copies into an event `properties={}` dict where a person-property method was the clear right call, or PII used as a fabricated `distinct_id`. Applies across ALL SDKs (client and server).
 - **eq_meaningful_naming** — Event names are descriptive and consistent (snake_case or consistent convention; names describe the action, not "event1" or "click")