bug: agent's own address is always masked, even when the caller is that agent

[nadavosa]

Problem

An NGO/agent viewing their own profile sees their own address masked (e.g. o***, 10407) instead of the real value. There's no privacy reason to mask an agent's address from the agent themselves.

Root cause

In src/server/utils/pii/mask.ts, the maskPii walker has a Person branch that correctly checks visibility before masking:

if (node instanceof Person) {
  const isVisible = ctx.personIds.has(node.id);
  if (!isVisible) {
    maskFields(node as unknown as Record<string, unknown>, PERSON_PII_FIELDS);
  }
  ...
}

But the standalone Address branch masks unconditionally, with no visibility check at all:

} else if (node instanceof Address) {
  // Reached not via a Person (e.g. agent.address) -> standalone PII, mask it.
  maskFields(
    node as unknown as Record<string, unknown>,
    ADDRESS_PII_FIELDS,
  );
}

There's also no Agent branch in the walker at all (only Person, Address, Opportunity, Comment), so when the walk descends into an Agent entity and reaches agent.address, it's masked as a plain standalone Address — regardless of whether ctx.agentIds (populated in resolveCallerVisibility, see src/server/utils/pii/visible-persons.ts) already contains that agent's own id.

Proposed fix

Add an Agent branch to the walker, mirroring the Person branch's pattern: if ctx.agentIds.has(node.id), treat the agent (and its address) as visible and skip masking, then seen.add(node.address) so the fallback standalone-Address branch doesn't re-mask it — same pattern already used for a visible Person's own address.

Acceptance criteria

• An AGENT-role caller viewing their own agent profile sees their own address unmasked
• Callers without visibility into a given agent (e.g. another agent, or a volunteer) still see that agent's address masked
• Existing masking behavior for Person, Opportunity accompanying, and Comment is unaffected

Related

• bug: NGO's own address is masked (e.g. "o***, 10407") even when viewing own profile fe#791 (closed in favor of this issue — original report was filed against fe before the root cause was traced to BE-side masking)