fix(postgres): RLS helper example revoked EXECUTE from roles that evaluate the policy

[cekuu35]

Summary

Fixes the bug reported in #390: the SECURITY DEFINER helper example in security-rls-performance.md revoked EXECUTE from all roles — including authenticated and service_role — and then used that same function inside an RLS policy.

Postgres evaluates policy expressions with the calling role's privileges, so any role whose queries can trigger the policy needs EXECUTE on every function the policy references. Following the previous example verbatim caused every authenticated query against the protected table to fail with:

permission denied for function private.is_team_member (SQLSTATE 42501)

What changed

• The example now revokes from PUBLIC only (which blocks uninvited direct calls — the actual security goal), then explicitly grants EXECUTE back to the roles that legitimately evaluate the policy (authenticated; commented examples for anon/service_role when their policies reference the helper).
• Added a short explanation of why the grant-back is required, so agents following the skill don't "fix" a 42501 by removing the revoke target from the policy or widening grants to everyone.
• Noted that internal helpers reached only through other definer functions/triggers — never referenced by a live policy or view — can remain fully revoked.
• Added the parallel rule for functions called inside view definitions, since the same failure mode shows up there.

Why this matters for agents specifically

An agent following the old example produces a project where auth appears "broken" after a security hardening pass. The shortest recovery path an agent typically takes is removing the hardening entirely. The corrected example gives agents a pattern that hardens correctly on the first pass and a diagnostic hint (42501 → check policy/view references) when it doesn't.