[perf/logging] `RequiredContentPack is being ignored` logged at WARNING per entry — ~16,800 lines per load

**Repo:** `BattletechModders/ModTek` · **File:** `ModTek/Features/Manifest/ModsManifest.cs`
**Branch verified:** `master` (as of 2026-05-24) · **Severity:** low / log-volume + I/O

## Summary
`UnsupportedFeatureContentPackRequirements()` logs a **`Warning`** for every manifest entry that
specifies a `RequiredContentPack` (an unsupported feature that ModTek then nulls out). In a
content-heavy pack like RogueTech — where thousands of entries carry `RequiredContentPack` — this
single line accounts for **16,809 log lines per session** in our captures (17/17 sessions), the
single largest contributor to `ModTek.log` size by three orders of magnitude.

```
[WARNING] Specified RequiredContentPack is being ignored. ← ×16,809 / load
```

It's pure noise: the message is identical every time, carries no per-entry detail, and is not
actionable by the player or pack author on a per-entry basis. The cost is string formatting +
disk writes for ~16.8k lines on every launch.

## Source
`ModTek/Features/Manifest/ModsManifest.cs` (lines ~374–389):

```csharp
private static void UnsupportedFeatureContentPackRequirements(ModEntry entry)
{
if (entry.RequiredContentPack != null)
{
Log.Main.Warning?.Log($"\t\tSpecified {nameof(entry.RequiredContentPack)} is being ignored.");
entry.RequiredContentPack = null;
}
}

private static void UnsupportedFeatureAddToDb(ModEntry entry)
{
if (!entry.AddToDB)
{
Log.Main.Warning?.Log($"\t\t{nameof(entry.AddToDB)}={entry.AddToDB} is being ignored");
}
}
```

(`AddToDB`'s sibling notice on line 387 has the same per-entry-warning shape and the same problem,
at lower volume.)

## Why a level-downgrade does NOT work here
A tempting one-liner is to downgrade these from `Warning` to `Debug`. **That does not reduce
volume in ModTek's default configuration:** `Log.Main` is created at `NullableLogger.TraceLogLevel`
(`Log.cs:8`), i.e. it emits *everything* including Debug and Trace. Captured logs confirm it —
they contain 16,245 `[DEBUG]` and 182 `[TRACE]` lines. Downgrading would merely relabel the 16,809
lines from `[WARNING]` to `[DEBUG]`; they'd still be written. The fix must stop emitting per entry.

## Suggested fix — aggregate to a single summary line
Count ignored entries during manifest processing and log one summary after the loop instead of one
line per entry. Concretely in `ModsManifest.cs`:

```csharp
// class fields (near line 25)
private static int s_ignoredContentPackEntries;
private static int s_ignoredAddToDbEntries;

// UnsupportedFeatureContentPackRequirements (~378): replace the per-entry Warning with a count
if (entry.RequiredContentPack != null)
{
s_ignoredContentPackEntries++;
entry.RequiredContentPack = null;
}

// UnsupportedFeatureAddToDb (~387): same
if (!entry.AddToDB)
{
s_ignoredAddToDbEntries++;
}

// end of BuildModdedBTRL(), after the `foreach (var modDef in mods)` loop:
Log.Main.Warning?.LogIf(s_ignoredContentPackEntries > 0,
$"Ignored unsupported RequiredContentPack on {s_ignoredContentPackEntries} manifest entries (feature not supported).");
Log.Main.Warning?.LogIf(s_ignoredAddToDbEntries > 0,
$"Ignored unsupported AddToDB=false on {s_ignoredAddToDbEntries} manifest entries (feature not supported).");
s_ignoredContentPackEntries = 0;
s_ignoredAddToDbEntries = 0;
```

This keeps a visible, actionable signal (the counts) while removing ~16.8k lines/load — the
dominant `ModTek.log` line family — and cuts per-launch log I/O substantially. The loop is
single-threaded (`BuildModdedBTRL` is a sequential enumerator), so plain counters are safe.

## Notes
- The root-cause *volume* originates in content packs declaring `RequiredContentPack` on entries
ModTek can't honor. That's arguably valid forward-looking metadata, so suppressing the log
(ModTek side) is the better fix than stripping the fields from every pack.

## Evidence
- `ModTek.log` search: `Specified RequiredContentPack is being ignored.` → 16,809 occurrences in
the latest captured session; present in all 17 sessions.

Start in ModTek/Features/Manifest/ModsManifest.cs around UnsupportedFeatureContentPackRequirements, UnsupportedFeatureAddToDb, and the BuildModdedBTRL loop; review Log.cs line 8 to understand the active logging level. Verify manifest loading produces summary counts instead of per-entry warnings, preserves the unsupported-feature behavior, and resets counts between loads.

Written by the indexing model from the issue text.