Artefact scope: tool indexes all .exe/.dll under the project tree, including unrelated files

[omonien]

Reported by: @mvandere (follow-up to #30, after #35 merged)

But why does the tool list all .exe's and .dll's in the project folder and below? (under the Artefacts heading). It's not as if these files can be somehow included in the main project, without being referenced 'elsewhere'.

DX.Comply currently emits an SBOM entry for every binary it finds while walking the project directory tree, irrespective of whether the build actually consumes it. For projects whose install/staging layout keeps unrelated tools, helpers, or sub-applications alongside the main artefact, this produces noisy SBOMs and SPDX validation problems (see also follow-up issues for duplicate SPDX IDs and locator spaces).

Why this matters

• The SBOM should describe the component that was built, plus its dependencies — not every binary that happens to coexist on disk.
• Sub-applications and bundled tools typically have their own SBOMs.
• The current behavior makes the artefact list opaque and inflates the deliverable.

Suggested directions (need a design decision)

1. Restrict the artefact scan to the OutputDir directory only (not recursive).
2. Restrict to the actual output filename(s) declared by the DPROJ (the most conservative).
3. Keep the current behavior but make it opt-in via a new flag (--scan-tree=<path> or --no-scan-tree).
4. Add an exclude glob set via .dxcomply.json so users can curate the artefact list.

Reproduction

Run DX.Comply against any project that has setup\ / tools\ / dist\ subdirectories with .exe or .dll files unrelated to the main target.

Acceptance criteria

• A reasonable default behavior chosen (likely option 1 or 2) so a typical project produces only artefacts that belong to the build.
• Existing users can opt back into the broader scan via an explicit flag if needed.