{{--
    The wireframe's status pill for an `is_active` boolean —
    docs/wireframes-v12/booking-type.html (~line 142) and
    customer-doc-type.html (~line 189), which both write:

        <span class="badge badge-success"><span class="dot"></span> Active</span>

    Every row those two wireframes draw is Active, so the pack never shows the
    other half. `badge-secondary` is what the false case renders as: it is one
    of the seven tones v12's stylesheet actually declares (style.css 379-385),
    it is the muted one, and style.css colours its `.dot` too. Not
    `badge-danger` — an inactive master is switched off, not broken — and not
    `badge-light`, which v12 has no rule for at all and would render as an
    unpainted pill (the trap recipe §0 records).

    Two class names come out of here and they mean different things, the way
    <x-status-badge> explains for the domain statuses: the tone carries the
    colour, and `status-active` / `status-inactive` carries the identity so a
    test or a later filter can address the pill by what it IS rather than by the
    colour it came out as.

    Nothing user-supplied reaches this file: the only input is a boolean, and
    both words are lang lookups.

    Why not <x-status-badge>? That component normalises its argument against
    three canonical *status* enums and falls back to "unknown" for anything
    else. `is_active` is a boolean flag with no lifecycle (CR-7 decision D2) and
    is not a member of any of them, so feeding it in would render "Unknown"
    twice. Same markup, same tokens, different question.

    Props:
        active — the boolean. Anything falsy renders the Inactive pill.
--}}
@props(['active' => true])

@php
    $isActive = (bool) $active;
    $key = $isActive ? 'active' : 'inactive';
    $tone = $isActive ? 'success' : 'secondary';
@endphp

<span {{ $attributes->merge(['class' => 'badge badge-'.$tone.' status-'.$key]) }}><span class="dot" aria-hidden="true"></span>{{ __('nrems.active_flag.'.$key) }}</span>