Report an empty metadata file as unparseable, not missing

[matt-edmondson]

Fixes #23

What was wrong

GeneratorBase.Initialize filtered out additional files with no text (.Where(file => file.Text.Length > 0)) before looking them up by name. An empty things.json that was correctly wired up was therefore reported as MetadataFileMissing, with the message "not supplied as an AdditionalFile". That message points the user at their .csproj, when the real problem is the file's contents. A whitespace-only file got past the filter and correctly reported MetadataParseFailed, so the two cases behaved inconsistently.

Change

• The filter is removed. An empty file, including one where GetText returned null, now reaches Deserialize and reports MetadataParseFailed.
• When several files share a name, the one chosen is now the first file with content, falling back to the first file. That keeps the filter's old effect on duplicates, as the issue suggests.
• A file that really is absent still reports MetadataFileMissing. AMissingMetadataFileIsReportedRatherThanSilentlyProducingNothing and AMultiFileGeneratorReportsEachFileThatIsAbsent still pass.

Behaviour change to review: AnEmptyMetadataFileCountsAsMissing came in with the initial extraction and pinned the old behaviour. It is replaced by AnEmptyMetadataFileIsReportedAsUnparseableNotMissing, which is the issue's acceptance test. It runs against both an empty and a whitespace-only file.

Tests

With GeneratorBase.cs reverted, the empty-file case fails. With the fix, the full suite passes: 49/49.

🤖 Generated with Claude Code

https://claude.ai/code/session_014jCUYfoRMwhybsUaSa1NFm

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud