tab groups can't be indented into lists

[shainaraskas]

Describe the bug

if you indent a tab set into a numbered list and two+ tab sets exist on the page, the tab set operates the first set of tabs all the time.

Screen.Recording.2025-02-20.at.4.59.27.PM.mov

it's not immediately apparent that something is wrong, and this is hard to diagnose - would be good to fix it to avoid accidental breakage

Expected behavior

I can indent a tab set and it operates independently

Steps to reproduce

use this snippet (sorry it's ugly and long)

## Step 1: Add a new realm configuration [ad-realm-configuration]

1. Add a realm configuration of type `active_directory` to `elasticsearch.yml` under the `xpack.security.authc.realms.active_directory` namespace. At a minimum, you must specify the Active Directory `domain_name` and `order`.

    See [Active Directory realm settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#ref-ad-settings) for all of the options you can set for an `active_directory` realm.

    :::{note} 
    Binding to Active Directory fails if the domain name is not mapped in DNS. 

    In a self-managed cluster, if DNS is not being provided by a Windows DNS server, you can add a mapping for the domain in the local `/etc/hosts` file.
    :::

  ::::{tab-set}

  :::{tab-item} Single domain
  The following realm configuration configures {{es}} to connect to `ldaps://example.com:636` to authenticate users through Active Directory:

  ```yaml
  xpack:
    security:
      authc:
        realms:
          active_directory:
            my_ad:  
              order: 0 <1>
              domain_name: ad.example.com <2>
              url: ldaps://ad.example.com:636 <3>
  ```

  1. The order in which the `active_directory` realm is consulted during an authentication attempt.
  2. The primary domain in Active Directory. Binding to Active Directory fails if the domain name is not mapped in DNS.
  3. The LDAP URL pointing to the Active Directory Domain Controller that should handle authentication. If you don’t specify the URL, it defaults to `ldap:<domain_name>:389`.
  :::

  :::{tab-item} Forest
  Set the `domain_name` setting to the forest root domain name.

  You must also set the `url` setting, since you must authenticate against the Global Catalog, which uses a different port and might not be running on every Domain Controller.

  For example, the following realm configuration configures {{es}} to connect to specific Domain Controllers on the Global Catalog port with the domain name set to the forest root:

  ```yaml
  xpack:
    security:
      authc:
        realms:
          active_directory:
            my_ad:
              order: 0
              domain_name: example.com <1>
              url: ldaps://dc1.ad.example.com:3269, ldaps://dc2.ad.example.com:3269 <2>
              load_balance:
                type: "round_robin" <3>
    ```

    1. The `domain_name` is set to the name of the root domain in the forest.
    2. The `url` value used in this example has URLs for two different Domain Controllers, which are also Global Catalog servers. Port 3268 is the default port for unencrypted communication with the Global Catalog; port 3269 is the default port for SSL connections. The servers that are being connected to can be in any domain of the forest as long as they are also Global Catalog servers.
    3. A load balancing setting is provided to indicate the desired behavior when choosing the server to connect to.


    In this configuration, users will need to use either their full User Principal Name (UPN) or their down-level logon name: 
    * A UPN is typically a concatenation of the username with `@<DOMAIN_NAME` such as `johndoe@ad.example.com`. 
    * The down-level logon name is the NetBIOS domain name, followed by a `\` and the username, such as `AD\johndoe`. 
    
      Use of down-level logon name requires a connection to the regular LDAP ports (389 or 636) in order to query the configuration container to retrieve the domain name from the NetBIOS name.
  :::

  ::::

  ::::{important} 
  When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain.
  ::::

4. Restart {{es}}.


## Step 2: Configure a bind user (Optional) [ece-ad-configuration-with-bind-user]

1. Configure the password for the `bind_dn` user by adding the appropriate `secure_bind_password` setting to the {{es}} keystore:


    :::::{tab-set}
    :group: cloud-eck-self

    ::::{tab-item} ECH and ECE
    :sync: cloud

    1. From the **Deployments** page, select your deployment.

        Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.

    2. From your deployment menu, select **Security**.
    3. Under the **{{es}} keystore** section, select **Add settings**.
    4. On the **Create setting** window, select the secret **Type** to be `Secret String`.
    5. Set the **Setting name** to `xpack.security.authc.realms.active_directory.<my_ad>.secure_bind_password` and add the password for the `bind_dn` user in the `secret` field.

        :::{warning}
        After you configure `secure_bind_password`, any attempt to restart the deployment will fail until you complete the rest of the configuration steps. If you wish to rollback the Active Directory realm related configuration effort, you need to remove the `xpack.security.authc.realms.active_directory.<my_ad>.secure_bind_password` that was just added by clicking **Remove** by the setting name under `Existing Keystores`.
        :::
    ::::

    ::::{tab-item} ECK
    [Create a secure setting](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-es-secure-settings) for the `xpack.security.authc.realms.active_directory.<my_ad>.secure_bind_password` setting using Kubernetes secrets.

    ::::

    ::::{tab-item} Self-managed

    ```shell
    bin/elasticsearch-keystore add  \
    xpack.security.authc.realms.active_directory.my_ad.secure_bind_password
    ```

    When a bind user is configured, connection pooling is enabled by default. Connection pooling can be disabled using the `user_search.pool.enabled` setting.
    ::::
    :::::

Tooling

• docs-builder
• migration tooling
• I'm not sure