Stop sibling re-enqueue from flooding mapping logs

The tracker-mapping worker re-arms same-banner siblings after a pattern
resolves a vendor. Its predicate only excluded promoted siblings
(third_party_id IS NULL), but since org-party auto-creation was dropped a
pattern can resolve a common third party yet never gain an org
third_party_id. Those siblings, and terminal first-party ones, stayed
eligible forever, so every cascade step re-enqueued and reprocessed them,
amplifying Process runs to O(N^2) per banner. The deadlock fix in the
last release removed the rollbacks that had accidentally throttled the
cascade, so the latent amplification surfaced as an INFO-log flood.

Tighten the re-enqueue to skip siblings already linked to a catalog row
that carries a common third party or marked FIRST_PARTY, dropping
per-banner reprocessing back to O(N). Also demote the two per-run handler
logs ("mapped tracker pattern", "re-enqueued unmapped sibling tracker
patterns") to Debug so routine processing no longer logs at INFO.

Signed-off-by: Émile Ré <emile@probo.com>

pkg/cookiebanner/tracker_mapping_worker.go

@@ -341,7 +341,7 @@ func (h *trackerMappingHandler) Process(ctx context.Context, tp coredata.Tracker
 				return fmt.Errorf("cannot update tracker pattern mapping: %w", err)
 			}
 
-			h.logger.InfoCtx(
+			h.logger.DebugCtx(
 				ctx,
 				"mapped tracker pattern",
 				log.String("pattern", tp.Pattern),
@@ -539,7 +539,7 @@ func (h *trackerMappingHandler) reenqueueUnmappedSiblings(
 	}
 
 	if count > 0 {
-		h.logger.InfoCtx(
+		h.logger.DebugCtx(
 			ctx,
 			"re-enqueued unmapped sibling tracker patterns",
 			log.String("tracker_pattern_id", tp.ID.String()),