fix(sdk): log spool warnings through SLF4J, not System.err

[JosteinGj]

Why

The SDK wrote its warnings straight to System.err. It runs inside other people's applications, so those messages bypassed the application's logging entirely: no levels, no routing, nothing a log pipeline or alert could pick up.

These are not noise. All four report spooled ingest data being lost or skipped:

• spooled datapoints dropped after a terminal error (TimeseriesService);
• spooled events dropped after a terminal error (EventService);
• an unreadable spool segment being skipped (DurableSpool);
• the spool directory being unlistable on recovery (DurableSpool).

Data loss is exactly what an operator wants in their logs.

What changes

• The four calls become SLF4J warn logs on the owning class's logger, with parameterised messages instead of string concatenation.
• slf4j-api is declared directly in the SDK. It already arrived transitively through datahub-api-model, so no new jar reaches consumers; it is declared because the SDK now uses it itself.
• The SDK's AGENTS.md gains the rule "log through SLF4J, never System.err/System.out".

Trade-off: an application with no SLF4J backend used to see these messages on the console and now will not. SLF4J prints one "no providers" notice instead. That is the standard behaviour for a library.

Docs

• datahub-sdk-docs: optional. It could mention that the SDK logs through SLF4J (logger names are the SDK class names), for anyone who wants to route or silence spool warnings.
• datahub-docs (operators): no change.

Verification

• :datahub-java-sdk:build is green, and no System.err or System.out remains in SDK main sources.
• Merges cleanly with build(sdk): make datahub-sdk publishable to Maven Central, with locally signed, CI-verified releases #148 and refactor(sdk)!: make DatahubClient the only way in #149; the combined tree builds green.

🤖 Generated with Claude Code