Fix two lint configuration traps

[StylianosGakis]

Bottom-but-one of stack #3125, on top of #3111 (which fixes develop's pre-existing ktlint failures). Two independent lint configuration fixes. Both surfaced while adding a new Gradle module, but neither is specific to it, so they are split out ahead of that work.

1. Only set the baseline when the module has one

HedvigLintConventionPlugin pointed baseline at hedvig-lint/lint-baseline/lint-baseline-<module>.xml unconditionally. Lint aborts the build whenever it has to create a baseline, so every module the plugin touched was implicitly required to carry a checked-in file, and adding any new module failed ./gradlew lint with a message that names neither the module nor the reason:

Aborting build since new baseline file was created

It does this even when lint found nothing to put in the baseline. Verified: with all findings suppressed, lint printed "Lint found no errors or warnings", wrote a 188-byte baseline, and failed anyway.

The second problem is worse. The baseline lint leaves behind records whatever it found, so the re-run it tells you to do passes, and any real error in the new module is suppressed from then on. Verified end to end on :cross-sells:

Step	Result
Plant a NamespaceImport violation, empty baseline	Lint found 1 error, build fails
updateLintBaseline, then lint again, violation still in the source	Lint found no new issues (and 1 error filtered by baseline), build succeeds

Setting baseline only when the file exists removes both. Modules that suppress findings today keep their baseline and behave exactly as before, and a module without one simply reports its findings. Verified by removing :apollo-test's baseline: lint no longer aborts, and no baseline is written.

This also makes the 104 empty baselines vestigial rather than load-bearing. Deleting them is deliberately left out of this PR.

2. Stop lint reporting version catalog staleness

GradleDependency and NewerVersionAvailable resolve against the shared root gradle/libs.versions.toml, not against the module being linted, so they report the same thing no matter which module runs lint. Only a module whose directory is a direct child of the repo root actually surfaces them, which is why they have never been visible: the only such included modules are hedvig-lint, which the plugin opts out of lint entirely, and a new one.

renovate.json already owns dependency freshness repo-wide, on a daily schedule, so these are duplicate signal that nobody acts on. Both are now severity="ignore" in the shared lint.xml, which is where this repo keeps issue configuration.

For scale, a single root-level module reported 77 of these: 19 GradleDependency and 58 NewerVersionAvailable, every one of them pointing at the root catalog rather than at the module.

Verification

• ./gradlew lint across the repo: passes.
• Both behaviours above verified directly rather than reasoned about, see the tables and notes.