refactor: name the actuator endpoint after Storm rather than the SQL log

[zantvoort]

Follow-up to #521, on the endpoint's name and on two files that PR missed.

The endpoint is Storm's, not the SQL log's

stormsqllog names the one subject the endpoint happens to carry today. Boot's own library endpoints are named after the library instead — flyway, liquibase, quartz, integrationgraph — and /actuator/storm reads like those, where /actuator/stormsqllog reads like a compound noun nobody remembers.

The payload is already sectioned per subject:

{
  "slowStatement": { "active": true, "threshold": "PT0.2S", "limit": 5 },
  "performance": { "request": { ... }, "entry-point": { ... } }
}

so claiming storm now costs nothing and lets anything else Storm learns to be told at runtime arrive as another section, rather than as a second endpoint standing next to a first one that only does SQL logging. Splitting later would be the expensive move.

StormSqlLogEndpoint becomes StormEndpoint so the type matches the umbrella rather than naming one section of it. The write parameters are unchanged.

Two files #521 missed

website/static/skills/storm-repository-kotlin.md and storm-repository-java.md still told readers to set storm.sql-log.call-sites: true, which no longer binds to anything. These are the skills applications vendor, so a stale key there is the one most likely to be copied into a real configuration. Both now name storm.sql-log.performance.call-sites and the threshold under performance, and both gained a sentence on the slow statement log, which they never mentioned at all.

The website/versioned_docs/version-1.13.* copies keep the flat keys deliberately: they document 1.13, where those keys were correct.

Verification

storm-spring 113 tests pass, spotless clean.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!