fix(ci): remove the duplicate ignore entries that broke the Dependabot config

[Ank-KhoaHo]

#373 shipped a .github/dependabot.yml that Dependabot refuses to parse. It appended the
fifteen shipped packages to two ignore lists that already named SixLabors.Fonts, so both gained a
duplicate:

The property '#/updates/2/ignore/18/dependency-name' is a duplicate.

Dependabot stops parsing the whole file on that, so every update it would raise is disabled —
security updates included. main has been in that state since #373 merged.

Caught by Dependabot's own API check appearing on #366, not by anything in this repo.

Why nothing here saw it

Three separate blind spots, all pointing the same way:

• check-dependabot-scoping.py reduces each block's ignore list to a set, so a duplicate is
  gone before it is examined
• yaml.safe_load accepts duplicate list items happily — they are list entries, not map keys
• the config check that objects is Dependabot's, and it runs on a PR touching the file, which
  ci: stop the chore block bumping shipped dependencies #373's own checks did not show before I merged it

Fixed

SixLabors.Fonts is no longer a standalone entry in either block; the derived list carries it. In
the root block that entry had an update-types: ["version-update:semver-major"] line under it —
removing only the name left the line orphaned and broke the YAML outright, which is worth recording
because it is the second way to get this wrong in one edit.

That is a deliberate widening: the root block ignored only SixLabors majors, the derived entry
ignores it entirely. Ignoring more is always safe, and src/ pins it to an exact version anyway.

Guarded

check-dependabot-scoping.py now counts each ignore list as a list rather than a set, using
this file's own line patterns.

Deliberately not via PyYAML. The first version of this check imported it inside a
try/except ImportError — and no workflow here installs PyYAML, so in CI it would have skipped
itself and reported success. A check that silently does nothing is worse than no check.

Sabotage-verified three ways, each duplicating a name that already exists in its own block:

duplicated	caught
Ank.DocToolkit	yes
OfficeIMO.Word	yes
Microsoft.Extensions.Hosting	yes

My first two sabotage attempts were ineffective — I added a name to a block that did not already
have it, so no duplicate existed and the check passed correctly. Worth stating: an ineffective
sabotage looks exactly like a guard that does not work.