Add service reachability, API version, and account commands

[MariusStorhaug]

Before a script starts pulling legal data it usually wants to know two things: is the service up, and does this key actually work. Today the only way to find out is to run a real data command and interpret the failure. There is also no way to check which Lovdata account a stored context belongs to, so a machine with several contexts gives no way to tell them apart beyond the name someone typed.

Request

Desired capability

Small commands that answer the operational questions directly: whether the API is reachable, which build is deployed, and which account a stored key belongs to. Reachability and version do not need a key at all, so they should work before anyone has connected, which also makes them usable as a first-run diagnostic.

Acceptance criteria

• Service reachability can be checked without a stored API key
• The deployed API version can be read without a stored API key
• The account behind a stored key can be inspected, returning the user and company identifiers Lovdata reports
• A rejected key produces the same clear message as any other command
• Tests pass without an API key, and the unauthenticated commands can be exercised against the live service in CI without one

References

• GET /ping answers Pong and needs no authentication
• GET /version returns the deployment name, timestamp, and revision, and needs no authentication
• GET /v1/userinfo returns userID, login, and companyID for the authenticated user

---

Technical decisions

Code placement: New group src/functions/public/Service/ with a Service.md overview.

Command naming: Test-LovdataConnection for reachability, Get-LovdataApiVersion for the deployment info, and Get-LovdataUser for the account behind a key. Test- returns a boolean and does not throw on an unreachable service, which is what makes it usable in a conditional.

Anonymous requests: The transport helper requires a context with an API key. /ping and /version need none, so the transport gains an explicit anonymous mode that skips header injection and falls back to the configured base URI. This is the same shape the module will need for the public data packages, so it is designed once here rather than twice.

Test approach: Unit tests mock the transport. Because these two endpoints are public, the suite can also carry a live smoke test against https://api.lovdata.no that needs no secret. Tag it so it can be excluded when running offline.

Depends on: the load-bearing core in #2. The pull request targets build-lovdata-module.

---

Implementation plan

Core changes

• Add an anonymous request mode to the transport helper under src/functions/private/API/
• Add Test-LovdataConnection under src/functions/public/Service/
• Add Get-LovdataApiVersion under src/functions/public/Service/
• Add Get-LovdataUser under src/functions/public/Service/
• Add the Service.md group overview page

Tests

• Add unit tests for each command against a mocked transport
• Add a test that an unreachable service makes Test-LovdataConnection return false rather than throw
• Add a tagged live smoke test for the unauthenticated endpoints

[MariusStorhaug]

Moved into the first release. Every endpoint this issue covers — /ping, /version, and the anonymous transport path — is part of Lovdata's open surface and needs no API key, so it belongs in #2 rather than in a later one.

One item does move out: Get-LovdataUser reads /v1/userinfo, which requires a key. It is folded into #15 with the credential store, since a command that reports which account a key belongs to has no meaning until keys can be stored.

The "anonymous request mode" framing in the technical decisions is now inverted: the transport has no key injection at all in the first release, so these commands are the normal path rather than an exception to it. Key injection is the later addition, described in #15.