Two required checks are a single echo; a third asserts a truth about arithmetic

[gHashTag]

docs/BRANCH-PROTECTION.md names five required checks. Read their bodies:

check	body	can it fail?
seal-coverage.yml	echo "Running SEAL coverage analysis..." (17 lines, 1 step)	no
schema-validation.yml	echo "Validating JSON schemas..." (15 lines, 1 step)	no
phi-loop-ci.yml — described as "Main test suite"	assert abs(phi**2 + phi**-2 - 3) < 1e-10, plus a real grep lint over ffi/src/	half — the assert is true of an empty repository
issue-gate.yml	47 lines of real logic	yes (it blocked one of my own PRs)

A required check that cannot fail reads as coverage and is worse than none. This is the same shape found four times today already: a gate green because it is narrow, blind, or vacuous.

What this PR does

Replaces schema-validation's echo with the weakest question worth asking — does every tracked JSON parse — chosen because it is cheap and carries no theory that could itself be wrong. It found something immediately:

• clara-bridge/audit-trail/experience-schema.json has a literal ... on line 40 and cannot parse
• clara-bridge/tests/run_tests.py:152 does json.load() on exactly that path
• 3 of its 11 tests were failing, measured by reverting the fix and re-running
• no workflow runs clara-bridge at all, so nothing said so

Fixed (one character), and the suite is now 11/11. Six empty JSON artefacts are recorded in tools/json_parse_baseline.txt as debts, one per line; external/ is excluded because tsconfig is JSONC by convention and flagging it would be this gate making the mistake it exists to catch.

What this PR does NOT do, deliberately

seal-coverage is left alone. .trinity/seals/ holds 1714 files keyed on names like Account, AXI4_Testbench and "[]const u8" — type names, not spec names. My first attempt scored coverage by matching seal filenames to spec filenames and produced "1668 orphans of 1714, 1024 specs of 1070 uncovered", which is not a finding about the repository but about my assumption. t27c has no seal subcommand. I could not establish what a real seal-coverage check should assert, so I wrote neither a check nor a deletion.

The vacuous half of phi-loop-ci is also left in place and reported here rather than changed, since the other half is a genuine lint and removing the assert is a judgement about what "main test suite" is supposed to mean.

Refs #2189