fix: filter 0002_auth_users_exposed pg_depend join by refclassid

[tushardev-365]

What

0002_auth_users_exposed joins pg_depend to auth.users on refobjid alone:

join pg_catalog.pg_depend d
    on d.refobjid = auth_users_pg_class.oid

refobjid is only unique within a catalog, so a view's rewrite dependency whose refobjid numerically collides with the auth.users pg_class oid, but actually references an object in a different catalog (e.g. a SECURITY DEFINER function in pg_proc), matches this join. The view is then reported as auth_users_exposed even though it has no dependency on auth.users, and the project gets a weekly critical "security vulnerability" email for it.

This is the issue reported in #171, with a reproduced collision (auth.users pg_class oid == a helper function's pg_proc oid) and a diagnostic query.

Fix

Qualify the referenced catalog on the join:

join pg_catalog.pg_depend d
    on d.refobjid = auth_users_pg_class.oid
    and d.refclassid = 'pg_catalog.pg_class'::regclass

This is the refobjid-side equivalent of the classid = 'pg_catalog.pg_class'::regclass filter the other pg_depend joins in the suite already use (0001, 0016, 0017), so it also brings 0002 in line with them.

splinter.sql was regenerated with bin/compile.py.

Testing

All 28 regression tests pass, so true-positive detection is unchanged:

======================
 All 28 tests passed.
======================

The collision itself depends on runtime oid assignment and can't be forced deterministically in the fixture-based suite, so there's no new failing-then-passing case; the existing 0002 true positives plus queries_are_unionable cover that the change is safe and the bundle still unions. Happy to add a characterization test if you'd prefer one.

Closes #171