[ABLD-366] Fix build file for cmd/loader so it can also build for macos. (#54739)

### What does this PR do?

Fix build file for cmd/loader so it can also build for macos.
- Remove unneeded target_compatible_with
- Adjust packaging to include it for macos.
- Fix dd_agent_go_binary so we can select() `exact_gotags`

We are blocked on ABLD-294 for using the loader in the real package, so we just have it named "loader" for now. We can build and verify that it works.

### Describe how you validated your changes
Make sure the loader builds and runs on mac.  Running it is subtle.
```
$ bazel build //cmd/trace-agent:trace-agent
Target //cmd/trace-agent:trace-agent up-to-date:
  bazel-bin/cmd/trace-agent/trace-agent_/trace-agent
INFO: Build completed successfully, 1 total action
$ cp bazel-bin/cmd/trace-agent/trace-agent_/trace-agent /tmp
$ bazel build //cmd/loader:loader
Target //cmd/loader:loader up-to-date:
  bazel-bin/cmd/loader/loader_/loader
$ bazel-bin/cmd/loader/loader_/loader /opt/datadog-agent/etc/datadog.yaml /tmp/trace-agent
...
2026-08-11 14:45:52 EDT | TRACE-LOADER | INFO | (pkg/util/log/log.go:734 in func1) | Starting to load the configuration
2026-08-11 14:45:52 EDT | TRACE-LOADER | ERROR | (pkg/util/log/log.go:815 in func1) | warning reading config
...
### Additional Notes

Co-authored-by: tony.aiuto <tony.aiuto@datadoghq.com> 27fda3f

Author: gh-worker-dd-mergequeue-cf854d[bot]

agent-schema/cli/index.html

@@ -4018,7 +4018,7 @@
 
 
 
-<h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>)<a class="headerlink" href="#cli-commands-dda-inv-schema" title="Permanent link">&para;</a></h1>
+<h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>)</h1>
 <p>The schema tooling is exposed through a set of <code>dda inv schema.*</code> invoke tasks
 (defined in <code>tasks/schema/</code>). This page documents each command, its arguments,
 and when you would run it.</p>
@@ -4027,7 +4027,7 @@ <h1 id="cli-commands-dda-inv-schema">CLI Commands (<code>dda inv schema.*</code>
 pipelines, so you rarely need to invoke them by hand — but they are useful when
 adding or editing settings, debugging schema problems, or regenerating output
 locally.</p>
-<h2 id="how-the-commands-fit-together">How the commands fit together<a class="headerlink" href="#how-the-commands-fit-together" title="Permanent link">&para;</a></h2>
+<h2 id="how-the-commands-fit-together">How the commands fit together</h2>
 <p>The schema files under <code>pkg/config/schema/yaml/</code> are the source of truth and are
 edited by hand (or through <code>schema.add-setting</code>). Everything else is derived from
 them:</p>
@@ -4043,7 +4043,7 @@ <h2 id="how-the-commands-fit-together">How the commands fit together<a class="he
   external consumers.</li>
 <li><code>schema.locate</code> finds where a setting is declared.</li>
 </ul>
-<h2 id="schemaadd-setting"><code>schema.add-setting</code><a class="headerlink" href="#schemaadd-setting" title="Permanent link">&para;</a></h2>
+<h2 id="schemaadd-setting"><code>schema.add-setting</code></h2>
 <p>Interactive wizard to add a new setting to the schema. It prompts for the
 setting name (dotted path), type, default, visibility, and description, then
 inserts the node into the correct schema file under <code>pkg/config/schema/yaml/</code>
@@ -4073,7 +4073,7 @@ <h2 id="schemaadd-setting"><code>schema.add-setting</code><a class="headerlink"
 public with a description. It runs <code>schema.lint</code> at the end so any remaining
 problems are visible.</p>
 <hr />
-<h2 id="schemalint"><code>schema.lint</code><a class="headerlink" href="#schemalint" title="Permanent link">&para;</a></h2>
+<h2 id="schemalint"><code>schema.lint</code></h2>
 <p>Validate the schema against the schema quality rules and exit
 non-zero on any violation.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.lint
@@ -4103,7 +4103,7 @@ <h2 id="schemalint"><code>schema.lint</code><a class="headerlink" href="#schemal
 </tbody>
 </table>
 <hr />
-<h2 id="schematemplate"><code>schema.template</code><a class="headerlink" href="#schematemplate" title="Permanent link">&para;</a></h2>
+<h2 id="schematemplate"><code>schema.template</code></h2>
 <p>Render a single config template (one build type, one OS) from the schema file. Useful for inspecting what a setting will
 look like in the generated example without running the whole build.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-2-1"><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.template<span class="w"> </span><span class="se">\</span>
@@ -4147,7 +4147,7 @@ <h2 id="schematemplate"><code>schema.template</code><a class="headerlink" href="
 template sections are included; the OS target controls which platform-specific
 defaults and <code>platform_only</code> settings are emitted.</p>
 <hr />
-<h2 id="schematemplate-all"><code>schema.template-all</code><a class="headerlink" href="#schematemplate-all" title="Permanent link">&para;</a></h2>
+<h2 id="schematemplate-all"><code>schema.template-all</code></h2>
 <p>Render every combination of build type × OS target from the core and
 system-probe schemas at once. This is what the build pipeline uses to keep the
 shipped <code>*.yaml.example</code> files in sync.</p>
@@ -4183,7 +4183,7 @@ <h2 id="schematemplate-all"><code>schema.template-all</code><a class="headerlink
 </tbody>
 </table>
 <hr />
-<h2 id="schemalocate"><code>schema.locate</code><a class="headerlink" href="#schemalocate" title="Permanent link">&para;</a></h2>
+<h2 id="schemalocate"><code>schema.locate</code></h2>
 <p>Find where a setting or section is defined in the schema source and print its
 node plus the exact file and line.</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-4-1"><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span>apm_config.enabled
@@ -4211,7 +4211,7 @@ <h2 id="schemalocate"><code>schema.locate</code><a class="headerlink" href="#sch
 </span><span id="__span-5-8"><a id="__codelineno-5-8" name="__codelineno-5-8" href="#__codelineno-5-8"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span><span class="s1">&#39;apm_config\..*enabled&#39;</span><span class="w"> </span>--json
 </span></code></pre></div>
 <hr />
-<h2 id="typical-workflows">Typical workflows<a class="headerlink" href="#typical-workflows" title="Permanent link">&para;</a></h2>
+<h2 id="typical-workflows">Typical workflows</h2>
 <p><strong>I edited a setting in the schema and want the Go code to reflect it:</strong></p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-6-1"><a id="__codelineno-6-1" name="__codelineno-6-1" href="#__codelineno-6-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.lint<span class="w">            </span><span class="c1"># validate the schema</span>
 </span><span id="__span-6-2"><a id="__codelineno-6-2" name="__codelineno-6-2" href="#__codelineno-6-2"></a>dda<span class="w"> </span>inv<span class="w"> </span>schema.codegen<span class="w">        </span><span class="c1"># regenerate pkg/config/setup from it</span>
@@ -4225,7 +4225,7 @@ <h2 id="typical-workflows">Typical workflows<a class="headerlink" href="#typical
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-8-1"><a id="__codelineno-8-1" name="__codelineno-8-1" href="#__codelineno-8-1"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span>apm_config.enabled<span class="w">   </span><span class="c1"># exact: node + file:line</span>
 </span><span id="__span-8-2"><a id="__codelineno-8-2" name="__codelineno-8-2" href="#__codelineno-8-2"></a>dda<span class="w"> </span>inv<span class="w"> </span>--<span class="w"> </span>schema.locate<span class="w"> </span><span class="s1">&#39;*enabled&#39;</span><span class="w">           </span><span class="c1"># pattern: all paths ending in &quot;enabled&quot;</span>
 </span></code></pre></div>
-<h2 id="see-also">See also<a class="headerlink" href="#see-also" title="Permanent link">&para;</a></h2>
+<h2 id="see-also">See also</h2>
 <ul>
 <li><a href="../">Introduction</a> — what the schema is and why it exists.</li>
 <li><a href="../keywords/">Keyword Reference</a> — the keywords these commands read and write.</li>

agent-schema/examples/index.html

@@ -3908,12 +3908,12 @@
 
 
 
-<h1 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">&para;</a></h1>
+<h1 id="examples">Examples</h1>
 <p>This page walks through three annotated examples taken from or inspired by the
 real schema files. Each example builds on the concepts introduced in the
 <a href="../keywords/">Keyword Reference</a>.</p>
 <hr />
-<h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple public setting node (<code>api_key</code>)<a class="headerlink" href="#example-1-simple-public-setting-node-api_key" title="Permanent link">&para;</a></h2>
+<h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple public setting node (<code>api_key</code>)</h2>
 <div class="language-yaml highlight"><pre><span></span><code><span id="__span-0-1"><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="nt">api_key</span><span class="p">:</span>
 </span><span id="__span-0-2"><a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="w">  </span><span class="nt">node_type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">setting</span><span class="w">    </span><span class="c1"># (1)</span>
 </span><span id="__span-0-3"><a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a><span class="w">  </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">string</span><span class="w">          </span><span class="c1"># (2)</span>
@@ -3945,7 +3945,7 @@ <h2 id="example-1-simple-public-setting-node-api_key">Example 1 — Simple publi
    and public documentation. Without this, the setting is considered internal.</li>
 </ol>
 <hr />
-<h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Section node with mixed children (<code>apm_config</code>)<a class="headerlink" href="#example-2-section-node-with-mixed-children-apm_config" title="Permanent link">&para;</a></h2>
+<h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Section node with mixed children (<code>apm_config</code>)</h2>
 <p>This example shows a section node taken from <code>pkg/config/schema/core_schema.yaml</code>
 with several child setting nodes, including one with a <code>platform_default</code>.</p>
 <div class="language-yaml highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="nt">apm_config</span><span class="p">:</span>
@@ -4009,7 +4009,7 @@ <h2 id="example-2-section-node-with-mixed-children-apm_config">Example 2 — Sec
    is known, eg. setting a value for <code>other</code> which is Darwin specific when you already have a value for Linux and Windows.</li>
 </ol>
 <hr />
-<h2 id="example-3-complex-nested-type-cel_workload_exclude">Example 3 — Complex nested type (<code>cel_workload_exclude</code>)<a class="headerlink" href="#example-3-complex-nested-type-cel_workload_exclude" title="Permanent link">&para;</a></h2>
+<h2 id="example-3-complex-nested-type-cel_workload_exclude">Example 3 — Complex nested type (<code>cel_workload_exclude</code>)</h2>
 <p>This example shows how JSON Schema's composable
 validation handles a non-trivial type. <code>cel_workload_exclude</code> corresponds to
 the following Go struct:</p>

agent-schema/faq/index.html

@@ -3974,9 +3974,9 @@
 
 
 
-<h1 id="faq">FAQ<a class="headerlink" href="#faq" title="Permanent link">&para;</a></h1>
+<h1 id="faq">FAQ</h1>
 <hr />
-<h2 id="how-do-i-add-a-new-setting">How do I add a new setting?<a class="headerlink" href="#how-do-i-add-a-new-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-add-a-new-setting">How do I add a new setting?</h2>
 <ol>
 <li>
 <p><strong>Determine the node type.</strong> If the setting holds a value (string, number,
@@ -4019,12 +4019,12 @@ <h2 id="how-do-i-add-a-new-setting">How do I add a new setting?<a class="headerl
 </span><span id="__span-0-4"><a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a><span class="w">  </span><span class="nt">description</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Enables the new feature.</span>
 </span></code></pre></div>
 <hr />
-<h2 id="how-do-i-deprecate-a-setting">How do I deprecate a setting?<a class="headerlink" href="#how-do-i-deprecate-a-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-deprecate-a-setting">How do I deprecate a setting?</h2>
 <blockquote>
 <p><strong>Note:</strong> [WIP] Automated solution coming soon.</p>
 </blockquote>
 <hr />
-<h2 id="how-do-i-make-a-setting-public">How do I make a setting public?<a class="headerlink" href="#how-do-i-make-a-setting-public" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-make-a-setting-public">How do I make a setting public?</h2>
 <ol>
 <li>
 <p><strong>Write a <code>description</code></strong> that explains what the setting does, what the default means, and any caveats. Every public
@@ -4057,7 +4057,7 @@ <h2 id="how-do-i-make-a-setting-public">How do I make a setting public?<a class=
 <p>The setting will appear in the configuration examples (ex: <code>datadog.yaml.example</code>) the next time the file is
 regenerated.</p>
 <hr />
-<h2 id="how-do-i-document-a-public-setting">How do I document a public setting?<a class="headerlink" href="#how-do-i-document-a-public-setting" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-document-a-public-setting">How do I document a public setting?</h2>
 <ol>
 <li><strong>Write a clear <code>description</code></strong> covering:</li>
 <li>What the setting does.</li>
@@ -4082,13 +4082,13 @@ <h2 id="how-do-i-document-a-public-setting">How do I document a public setting?<
 <li><strong>Set <code>visibility: public</code></strong> to include the setting in generated output.</li>
 </ol>
 <hr />
-<h2 id="how-do-i-generate-datadogyamlexample">How do I generate <code>datadog.yaml.example</code>?<a class="headerlink" href="#how-do-i-generate-datadogyamlexample" title="Permanent link">&para;</a></h2>
+<h2 id="how-do-i-generate-datadogyamlexample">How do I generate <code>datadog.yaml.example</code>?</h2>
 <p>The generation of <code>datadog.yaml.example</code> from the schema is wired into the
 Agent's build pipeline and runs automatically. Developers do not normally need
 to trigger it manually.</p>
 <p>If you want to validate the generated example you can use <code>dda inv schema.template-all</code> command.</p>
 <hr />
-<h2 id="what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample">What is the difference between <code>datadog.yaml.example</code> and <code>system-probe.yaml.example</code>?<a class="headerlink" href="#what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample" title="Permanent link">&para;</a></h2>
+<h2 id="what-is-the-difference-between-datadogyamlexample-and-system-probeyamlexample">What is the difference between <code>datadog.yaml.example</code> and <code>system-probe.yaml.example</code>?</h2>
 <p>Each configuration file has its own schema and its own generated example file:</p>
 <ul>
 <li>

agent-schema/index.html

@@ -3870,19 +3870,19 @@
 
 
 
-<h1 id="agent-configuration-schema">Agent Configuration Schema<a class="headerlink" href="#agent-configuration-schema" title="Permanent link">&para;</a></h1>
+<h1 id="agent-configuration-schema">Agent Configuration Schema</h1>
 <p>The Datadog Agent configuration schema is a YAML-based
 <a href="https://json-schema.org/">JSON Schema</a> that centrally describes every
 configuration setting for the Agent. It is written in YAML for readability but
 is fully compatible with JSON Schema tooling.</p>
-<h2 id="why-it-exists">Why it exists<a class="headerlink" href="#why-it-exists" title="Permanent link">&para;</a></h2>
+<h2 id="why-it-exists">Why it exists</h2>
 <p>Previously, Agent configuration was defined through a combination of imperative Go code (<code>BindEnvAndSetDefault</code> calls in
 <code>pkg/config/setup</code>), YAML example files maintained by-hand, and scattered validation logic. This made it hard to
 understand what a setting does, what values it accepts, or what its default is — without reading source code.</p>
 <p>The schema replaces this with a <strong>single source of truth</strong>. All information
 about a setting — its type, default value, documentation, environment variables,
 validation rules, and visibility — lives in one place.</p>
-<h2 id="what-it-enables">What it enables<a class="headerlink" href="#what-it-enables" title="Permanent link">&para;</a></h2>
+<h2 id="what-it-enables">What it enables</h2>
 <ul>
 <li><strong>Config validation without running the Agent</strong> — any JSON Schema library can
   validate a customer's <code>datadog.yaml</code> against the schema.</li>
@@ -3896,15 +3896,15 @@ <h2 id="what-it-enables">What it enables<a class="headerlink" href="#what-it-ena
 <li><strong>Runtime validation</strong>  — The user configuration can be validate at runtime by the Agent allowing automatic fallback
   to default upon an invalid value.</li>
 </ul>
-<h2 id="terminology">Terminology<a class="headerlink" href="#terminology" title="Permanent link">&para;</a></h2>
+<h2 id="terminology">Terminology</h2>
 <ul>
 <li><strong>Path</strong> — a string of terms separated by dots (<code>"."</code>) that represents a series of nodes in the config tree.</li>
 <li><strong>Setting</strong> — a configurable value that can be located using a path (example <code>apm_config.enabled</code>)</li>
 <li><strong>Section</strong> — a groupping of settings under a common name (example <code>apm_config</code>)</li>
 <li><strong>Object</strong> — a data type of key-value pairs. Also called a map (in Go) or dict (in Python), but called an object in JSON Schema since it comes from JavaScript.</li>
 <li><strong>Default</strong> — the value that will be retrieved for a given setting if none is specified by the user's file-based configuration or environment variable (or other source).</li>
 </ul>
-<h2 id="node-types">Node types<a class="headerlink" href="#node-types" title="Permanent link">&para;</a></h2>
+<h2 id="node-types">Node types</h2>
 <p>The schema tree is composed of two types of nodes:</p>
 <ul>
 <li><strong>Setting nodes</strong> represent individual settings. They have a type and a value.
@@ -3917,7 +3917,7 @@ <h2 id="node-types">Node types<a class="headerlink" href="#node-types" title="Pe
 <p>The distinction matters when a setting's value is an object. For example, <code>docker_labels_as_tags</code> is a <code>type: object</code>
 setting node — its value is a dict of strings, but that dict is the setting's <em>value</em>, not a group of child settings. It
 is a setting node, and <strong>not</strong> a section node.</p>
-<h2 id="one-schema-per-configuration-file">One schema per configuration file<a class="headerlink" href="#one-schema-per-configuration-file" title="Permanent link">&para;</a></h2>
+<h2 id="one-schema-per-configuration-file">One schema per configuration file</h2>
 <p>The Agent ships with multiple configuration files, each with its own schema:</p>
 <table>
 <thead>
@@ -3938,12 +3938,12 @@ <h2 id="one-schema-per-configuration-file">One schema per configuration file<a c
 </tbody>
 </table>
 <p>All schemas share the same keyword set described in this documentation.</p>
-<h2 id="json-schema-foundation">JSON Schema foundation<a class="headerlink" href="#json-schema-foundation" title="Permanent link">&para;</a></h2>
+<h2 id="json-schema-foundation">JSON Schema foundation</h2>
 <p>The Agent schema builds on <a href="https://json-schema.org/">JSON Schema draft 2020-12</a>.
 This documentation focuses on how keywords are used in the Agent schema
 specifically. For a general introduction to JSON Schema, see
 <a href="https://json-schema.org/understanding-json-schema">Understanding JSON Schema</a>.</p>
-<h2 id="next-steps">Next steps<a class="headerlink" href="#next-steps" title="Permanent link">&para;</a></h2>
+<h2 id="next-steps">Next steps</h2>
 <ul>
 <li><a href="keywords/">Keyword Reference</a> — complete reference for all supported keywords.</li>
 <li><a href="examples/">Examples</a> — annotated, real-world examples from the schema.</li>