Running The Threats Skill Doesn't Create Mappings Properly

## Bug Report

You're right to flag this — the file storage threats.yaml has no external-mappings blocks at all, and that's a gap relative to what the skill describes as the final outcome.

What the skill expects

The threat-catalog skill says each service-specific threat should include external-mappings where confident:

```
external-mappings:
- reference-id: MITRE-ATT&CK
entries:
- reference-id: T1039
remarks: Data from Network Shared Drive
- reference-id: D3FEND
entries:
- reference-id: D3-NI
remarks: Network Isolation

Step 4 did use ATT&CK/D3FEND/CWE for discovery (they appeared in the planning table), but Step 5 did not write them into YAML.
```

### Why they were omitted

The skill has a mapping-reference gate:
A framework may appear in external-mappings only if its reference-id is declared in metadata.mapping-references.
Your metadata.yaml currently only declares:

```
metadata.yaml
Lines 25-28
mapping-references:
- id: CCC.Core
title: FINOS CCC Core Catalog
version: v2025.10
```

So per the skill, MITRE-ATT&CK, D3FEND, CISA-KEV, CWE, and OWASP-Top-10 could be used for reasoning but not emitted in threats.yaml. The skill also says not to edit metadata.yaml during the threat step — only to recommend additions.
That recommendation was surfaced at Step 4 (Recommended metadata.mapping-references additions: MITRE-ATT&CK, D3FEND, CWE) but wasn't acted on.
Imported core threats ≠ missing mappings

For the 16 imported core threats (CCC.Core.TH01, etc.), framework mappings do exist — in the core catalog, not repeated in the service file:
```
threats.yaml
Lines 19-45
external-mappings:
- reference-id: MITRE-ATT&CK
entries:
- reference-id: T1078
remarks: Valid Accounts
...
```

Service imports are references by ID; they don't copy ATT&CK blocks into file-storage/threats.yaml. At compile time, those resolve against CCC.Core.Threats.