fix(568): one ordinal identity predicate for the built-in element, applied in memory at both sites

The branch moved the `builtIn` discriminator from a bare filename to the full
seeded path, but split how the two sites evaluate it: the API handler compares
in memory (ordinal) while GetBuiltInElementId's new `.Where(e => e.Path ==
OnNowNextSeededPath)` compares in SQL. GraphicsElement.Path takes no explicit
collation -- TvContext.OnModelCreating pins one only on the listed name/title
columns -- so SQLite answers that case-sensitively and MySQL uses the server
default, which is normally case-INsensitive. On MySQL the two discriminators
could therefore disagree about the same row: AttachOnNowNextByDefault would
resolve a case-variant user element as the built-in one while the API reported
builtIn:false for it.

Collapse both onto GraphicsElementDefaults.IsOnNowNext, ordinal, applied in
memory. GetBuiltInElementId goes back to loading the Text candidates and
filtering in memory (the shape it had before this branch), keeping only the
`Kind` enum filter in SQL.

The prose claimed more than the code did. "A filename-only comparison is
case-sensitive-by-accident" appeared in four places as a defect the full-path
fix removed; a full-path comparison is exactly as case-sensitive, so the clause
said nothing and implied a fix that had not happened. Case sensitivity is now
deliberate and stated as such -- the built-in element is the exact file the
seeder wrote, at the exact path it wrote it to -- and the reason the comparison
is kept out of SQL is recorded where the predicate lives.

docs/decisions/records/graphics/channel-level-attachment.md said BuiltIn was
"computed by comparing the row's `Path` to GraphicsElementDefaults.
OnNowNextFileName", which was true of neither the pre-#568 rule (filename to
filename) nor the current one; an active record resolved by key now states the
current predicate in its own sentence rather than in a parenthetical.

Two tests pin the ordinal rule against a loosening to OrdinalIgnoreCase, one
per site. Measured: OrdinalIgnoreCase reddens exactly
GetAllGraphicsElementsForApi_Should_Not_Mark_A_Case_Variant_Of_The_Seeded_Path_As_BuiltIn
and Ignores_A_Case_Variant_Of_The_Seeded_Path, 2 failed / 77 passed of the 79
graphics tests. They do NOT pin provider independence -- under SQLite's BINARY
collation an equivalent SQL comparison answers identically, so no test in this
suite can distinguish the two. That is stated at each site rather than left for
a reader to assume the tests cover it.

Decisions-Edit: yes

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV

docs/graphics-elements.md

@@ -121,12 +121,20 @@ never overwrites an operator's file. Two rules govern it after that:
 - Updating the shipped default → `graphics.seeded-template-upgrade-by-fingerprint`.
 - It is attached to channels by default → `graphics.on-now-next-on-by-default`.
 
-Identity is the **full seeded path** (`GraphicsElementDefaults.OnNowNextSeededPath`), never the editable
-`Name` and never the bare filename (`OnNowNextFileName`) alone — a filename-only, folder-agnostic
-comparison let a user element named exactly `on-now-next.yml` in a different template folder also
-report `builtIn:true` (#568). `GraphicsElementResponseModel.BuiltIn` and
-`GraphicsElementSeeder.GetBuiltInElementId` both compare against the full path server-side so the SPA
-never name-matches.
+Identity is the **full seeded path**, never the editable `Name` and never the bare filename
+(`OnNowNextFileName`) alone — a filename-only, folder-agnostic comparison let a user element named
+exactly `on-now-next.yml` in a different template folder also report `builtIn:true` (#568). Both
+`GraphicsElementResponseModel.BuiltIn` and `GraphicsElementSeeder.GetBuiltInElementId` resolve it
+through the one predicate, `GraphicsElementDefaults.IsOnNowNext`, so the SPA never name-matches.
+
+`IsOnNowNext` is **ordinal**, and every caller applies it **in memory** rather than in a `Where`
+clause. That is not incidental: `GraphicsElement.Path` takes no explicit collation (`TvContext`
+pins one only on the listed name/title columns), so a SQL `Path ==` comparison is case-sensitive
+under SQLite and normally case-INsensitive under MySQL. Evaluating one of the two discriminator
+sites in SQL and the other in memory is what would let them disagree, on MySQL only. The SQLite test
+suite cannot distinguish the two — BINARY collation and an ordinal comparison agree on every input —
+so this is held by keeping the comparison out of SQL, not by a test; what the case-variant tests in
+the table below pin is the ordinal rule itself, against a loosening to `OrdinalIgnoreCase`.
 
 ## Tests