[Documentation] `allow_insecure` discrepancy in `Recommended hardening`

Hello, I've been looking at some of the documentation around the security model for apm and noticed a discrepancy in the Recommended hardening section related to allow_insecure.

TL;DR

The apm docs and source code agree on the mechanics. There is no dedicated
policy key for insecure transport; the docs' recommended hardening leans on
the general dependency allow list. The one soft discrepancy is that the docs
imply a policy-level control that the source only implements indirectly.

What the source code shows

• allow_insecure is a per-dependency manifest key in apm.yml
  (boolean), defined in docs/.../reference/manifest-schema.md:427.
• Enforcement is a two-gate model in src/apm_cli/install/insecure_policy.py:
  an HTTP dep is allowed only if both (1) the dep entry has
  allow_insecure: true and (2) the install runs with --allow-insecure.
• The policy engine (src/apm_cli/policy/) contains zero references to
  "insecure". Transport security is enforced in the install pipeline, not the
  policy layer.
• allow_non_registry (under registry_source) is a separate, experimental
  control governing source routing (registry vs. git/local), unrelated to
  http:// transport. Requires apm experimental enable registries.

What the documentation says

• Recommended hardening (enterprise/security.md:491), verbatim:

  "Forbid allow_insecure: true via the policy allow list, except where an
  air-gapped mirror demands it."

The discrepancy

The docs phrase it as though a purpose-built anti-insecure toggle exists at the
policy layer. In reality, the only lever is the general dependency allow/deny
glob list: because it matches a host-blind, scheme-blind canonical ref
(owner/repo), an http:// mirror simply fails to match a vetted glob and is
blocked as a side effect — not through any allow_insecure-aware policy check.

Practical takeaway

• You cannot block insecure deps with a policy key like allow_insecure: false.
• You cannot rely on allow_non_registry: false for it either (separate axis,
  experimental).

Start with enterprise/security.md around line 491 and compare its Recommended hardening wording with docs/.../reference/manifest-schema.md:427 and src/apm_cli/install/insecure_policy.py. Update the documentation so it does not imply a dedicated policy key or confuse allow_non_registry with transport security. Done means the documented control matches the two-gate behavior and general dependency allow/deny mechanism.