docs: asset kinds and per-source asset aliases

[devGregA]

Description

Documentation for the asset-identity work in DefectDojo Pro (asset model, Phase 4). Docs-only; no code changes.

Two pages gain sections:

Assets (Pro) — docs/content/asset_modelling/engagements_tests/PRO__assets.md

• Asset Kinds. An Asset can declare what kind of thing it is (repository, service, host, domain, container image, package, cloud account, device, branch). Optional and descriptive: it changes no permission, no deduplication, no SLA, and no reporting scope. The list is an editable registry rather than a fixed set — shipped kinds cannot be deleted, but their wording and icons can change and customers can add their own.
• Asset Identity: Aliases. Per-source identifiers, keyed by namespace, type and value, so an Asset can be recognised from whichever name a given source uses. Covers the one-identifier-one-Asset rule, why user-asserted aliases survive automation, why the connector: namespace is written by sync rather than by hand, and why there is no update action (an identifier is asserted or withdrawn — editing one in place would re-point identity leaving no trace of what it used to mean).

Manage Records (connectors) — docs/content/connectors/upstream/manage_records.md

• How Auto-Mapping chooses the Product. The resolution order — the tool's own identifier, then the name, then a new Product — and what that changes: a rename in the tool or in DefectDojo no longer loses the Mapping or creates a duplicate, and two tools that each report something called payments stop being permanently fused by that coincidence. Also records that enabling the feature changes nothing about existing Mappings, and that remapping a Record by hand always wins.

Both features sit behind DD_V3_ASSET_ALIASES, which is off by default; the docs say so where it matters.

Test Configuration

Documentation only — no application code is touched.