fix: push-notification config logged at INFO including webhook auth credentials

[KonstantinMirin]

Summary

src/core/tools/media_buy_create.py:2037 logs the full push_notification_config at INFO level — including the authentication block, i.e. the buyer's webhook bearer token/credentials. Anyone with log access (aggregators, CI artifacts, support tooling) can replay the buyer's webhook auth.

Provenance: pickaxe dates it to the #1107-era push-notification work; untouched since. Not related to the adcp 6.6 bump — surfaced during PR #1567 review.

Relation to #1450

#1450 tracks the CodeQL logging-hygiene backlog and classifies the py/clear-text-logging-sensitive-data alerts as "mostly false-positive — logs about credentials... not the secret". This site is the exception: it logs the secret itself. Filing separately so the true positive doesn't ride the backlog's timeline.

Fix

• Log a redacted view — config id / url / principal, with the authentication block masked. The sanctioned seam already exists: src/core/log_safety.loggable (named by Reduce the CodeQL alert backlog: logging hygiene + per-PR differential scanning #1450 as the repo convention; src/services/idempotency_replay.py shows the pattern and carries 0 alerts).
• Grep for sibling log sites in the same flow (media_buy_update, webhook delivery/registration paths) and apply the same redaction.
• Regression: assert the rendered log line never contains the credential value (drive the real create path with a config carrying authentication, capture via caplog, assert absence).

Acceptance

• No log line in the push-notification flow contains authentication credential material.
• Regression test goes red if the raw config is logged again.