Name the datapoint in the counter type error (#320)

[GermanBluefox]

Fixes #320.

Counter must have type "number"! said nothing about which datapoint it meant. The reporter asked for the ID in 2023; a second user commented that they had been living with it for over a year without being able to find the misconfigured datapoint, and a third eventually located theirs by reading the raw object JSON for "counter": true.

Before / after

Counter must have type "number"!

Counter must have type "number", but "modbus.5.inputRegisters.30536_Quellentemperatur"
is stored as "String". Change the storage type of this datapoint to "Number",
or switch the counter option off.

The ID is what makes it searchable; the actual type and the two ways out are what make it actionable without guessing.

Logged once per datapoint, not once per value

The check sits in pushHistory, so the old message fired for every value of the misconfigured datapoint — the screenshot in the issue is a wall of the same line. Adding the ID without throttling would only have made that wall wider, so a counterTypeReported flag on the datapoint reports it once. The flag lives on the per-datapoint config, which objectChange rebuilds, so correcting the configuration lets it report again if it is still wrong.

Two siblings in the same path

No Connection to database appeared twice with the datapoint ID available right there and unused:

• prepareTaskCheckTypeAndDbId() → No connection to the database, cannot store the value of "<id>"
• #readIdIndexAndType() → No connection to the database, cannot look up "<id>"

Verification

The text is built by counterTypeMismatch() in src/lib/errors.ts rather than inline, so it is unit testable without importing main.ts — which pulls in @iobroker/adapter-core and exits the process when js-controller cannot be resolved (the constraint #567 established). Two cases added to test/testErrors.js, which the CI unit list already runs: that the ID, the current type, the target type and the alternative all appear and stay on one line, and that an unmapped storage type does not produce "undefined".

144 unit tests pass; check:ts and prettier --check are clean on the changed files. (prettier --check README.md reports findings already present on master, so the file is left as it is apart from the changelog line.)

🤖 Generated with Claude Code