Campaign card header slots with per-campaign context

The campaign card header (rendered by he-campaign-list-layout-card and he-campaign-detail) now contains two interior slots you can inject custom content into with the existing hapi.ui.service.appendChildToSlot API:

• card-campaign-header--prepend — first element inside the header, above the Job ID row
• card-campaign-header--append — last element inside the header, below the status / dates / price row

Per-campaign context via data attributes

Unlike the widget-boundary --before / --after slots, the campaign card header repeats once per campaign, so each slot instance carries data attributes describing its campaign:

Attributes whose value is not set on the campaign are omitted.

This makes per-campaign content possible with pure CSS — for example replacing the built-in Job ID: … text with your own reference:

// 1. Hide the built-in Job ID text
window.hapi.ui.service.hideElement(".hapi__card-campaign-header-job-id")

// 2. Show your own reference per campaign
window.hapi.ui.service.addStyleSheet(
    "custom-campaign-reference",
    `slot.card-campaign-header--prepend::after {
        content: "Job ID: " attr(data-order-reference);
        font-size: 0.75rem;
    }`
)

Repeated-slot injection is now idempotent

appendChildToSlot appends the element to every matching slot. Previously, when a slot id existed multiple times on the page (for example one per campaign card), each newly mounting instance could re-trigger the injection and append duplicate copies into slots that already had the element. Injection now skips slots that already contain the element (matched by its internal data-custom-element-id), so list re-renders and pagination no longer duplicate injected content. Event callbacks (onclick etc.) are now attached to the copy inside each slot instance, not only the first one on the page.

Backwards compatibility

• Purely additive: two new <slot> elements and their data attributes. No element, CSS class, SDK function, or event was removed or renamed.
• Existing single-instance slots behave exactly as before; the idempotency guard only prevents appending the same element twice into the same slot, which was never intended behavior.