Fix stale v4.0.3-4.3.3 <-> v5.0.0-13.2.4 mapping

[Sofeso]

Related to #3344 (does not close it — see "Scope" below).

Problem

mapping_v5.0.0_to_v4.0.3.yml and mapping_v4.0.3_to_v5.0.0.yml both claim v5.0.0-13.2.4 is a modified/moved version of v4.0.3-4.3.3. That's no longer accurate:

• v4.0.3-4.3.3 was about requiring step-up auth / multi-user approval before changing credential or connection-parameter configuration for database/service integrations.
• Current v5.0.0-13.2.4 reads: "Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate..." — a completely different topic (application-layer allowlisting, the counterpart to 13.2.5's server-layer allowlisting).

Independent verification

I re-derived the facts in #3344 myself rather than taking the issue at face value:

1. Confirmed 13.2.5's lineage is intact: 4.0/en/0x20-V12-Files-Resources.md V12.6.1 ("Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.") matches current V13.2.5 almost word-for-word — consistent with 13.2.5's own tag (GRAMMAR, MOVED FROM v4.0.3-12.6.1).
2. Confirmed 13.2.4 has no v4.0.3 lineage at all: searched all of 4.0/en/*.md for wording resembling 13.2.4's actual text (allowlist + external + communicate) — no match anywhere. It's genuinely new content in v5.0.0, not a "modified" version of anything.
3. Confirmed exactly where the mapping went stale: the intermediate bleeding-edge files (mapping_v4.0.3_to_v5.0.be.yml, mapping_v5.0.be_to_v4.0.3.yml) correctly show v4.0.3-4.3.3 -> v5.0.be-14.7.3, and mapping_v5.0.be_to_v5.0.0.yml correctly renumbers v5.0.be-14.7.3 -> v5.0.0-13.2.4. That renumbering was accurate at the time. It's only the two final v4.0.3<->v5.0.0 mapping files that are stale, because — per the commit history V4.3.3-derived requirement accidentally deleted, mapping is stale #3344 lays out — 13.2.4's text (not its ID) was later overwritten by unrelated 12.6.1-derived content. So I only touched those two files; the "be" intermediate mappings still correctly describe history and don't need changes.

Change

 v4.0.3-4.3.3:
-  tag-v5.0.0: MOVED TO v5.0.0-13.2.4
+  tag-v5.0.0: DELETED

 v5.0.0-13.2.4:
-  tag-v4.0.3: MODIFIED, MOVED FROM v4.0.3-4.3.3
+  tag-v4.0.3: ADDED

Scope — what this PR intentionally does NOT do

#3344 also asks whether the lost 4.3.3-derived control (step-up auth for credential/connection config changes) should be restored as a new requirement. That's a substantive content/policy decision for ASVS maintainers, not something I'm deciding via this PR. This PR only fixes the factual bookkeeping error so the mapping accurately reflects what the standard says today. I've left #3344 open rather than marking it closed, since that question is still unresolved.

Disclosure

I used AI assistance (Claude) to investigate this issue and draft the fix, including independently re-verifying the git-archaeology claims in #3344 against the actual file contents rather than trusting them directly. I reviewed the evidence and take responsibility for the change.

[elarlang]

Thank you for digging into it, but for approving it, I need to re-analyze issues #3343 and #3344 and it may take some (calendar) time to happen.