Story: IAM/Refdata service boundary cleanup

ores.iam.core crosses the service boundary in two known places, reading/writing ores_refdata_parties_tbl directly instead of going through ores.refdata. These are pre-existing violations noted in the three-level provisioning plan's "Known pre-existing violations". Fix both so RLS enforcement and service ownership are clean.

• bootstrap_handler.hpp's direct ores_refdata_parties_tbl write is replaced with a refdata.v1.parties.save NATS call.
• auth_handler.hpp's direct ores_refdata_parties_tbl query (auth_lookup_party) is replaced with a refdata.v1.parties.get-by-principal NATS call (endpoint added to ores.refdata if missing).
• RLS policies are verified still enforced end-to-end after the refactor.
• ores.iam.core's CMake no longer depends on cross-schema ores_refdata_* table includes.

Planned tasks (not yet scaffolded as task docs):

1. Replace bootstrap_handler.hpp's direct ores_refdata_parties_tbl write with a refdata.v1.parties.save NATS call.
2. Replace auth_handler.hpp's direct ores_refdata_parties_tbl query with a refdata.v1.parties.get-by-principal NATS call, adding the endpoint to ores.refdata if missing.
3. Verify RLS policies still enforced end-to-end after the refactor.
4. Remove cross-schema table includes from ores.iam.core CMake deps.

• Any refdata boundary violations outside ores.iam.core (see DQ/Refdata service boundary cleanup for the DQ side).