Add full-text search across Lovdata legal sources

[MariusStorhaug]

A user who works with Norwegian legal material rarely knows a document identifier up front. The starting point is a phrase, a topic, or a date range: "everything about arbeidstid in acts from the last two years". Today the module can list which legal sources exist, but there is no way to find documents inside them, so any real workflow still ends in a browser.

Request

Desired capability

A Search-LovdataDocument command that runs a full-text search across the legal sources the account can reach and returns the hits as objects that can be filtered, sorted, and piped into later commands. It should be able to narrow by legal source, by subject terms, and by date range, and it should return every hit rather than only the first page, because a script that silently sees one page of results produces wrong answers without saying so.

Acceptance criteria

• A phrase search returns matching documents as objects carrying at least the document identifier, title, and legal source
• Results can be narrowed to one or more legal sources, by subject terms, and by a date range
• All matching results are returned by default; limiting the result set is opt-in and explicit
• The number of available hits is discoverable, so a caller can tell whether a query is too broad
• No silent truncation: if anything limits the result set, the caller can see it
• The command works through the stored context like every other command, and its tests pass without an API key

References

• GET /v1/search accepts emne1, emne2, emne3, teksthenvisning, base, rows, offset, sortField, sortOrder, fromDate, and toDate

---

Technical decisions

Code placement: New group src/functions/public/Search/, with the group overview in Search.md. A LovdataSearchResult class under src/classes/public/ models a hit.

Command naming: Search-LovdataDocument. Search is an approved verb and describes the intent; the noun names the resource being searched, not the endpoint.

Paging: The endpoint pages with rows and offset, which is the first paged endpoint in the module. The paging loop belongs in the transport layer next to Invoke-LovdataAPI rather than inside the public command, so the next paged endpoint reuses it. Default behaviour is to follow every page; a -First style parameter caps the result set explicitly.

Parameter design: Follow the object-first rule and give the search its own parameters rather than exposing the raw query names: -Query, -Subject (mapped onto emne1..emne3), -LegalSource, -From, -To, -SortBy, -SortOrder. The Norwegian API parameter names stay internal.

Test approach: Unit tests mocking Invoke-LovdataAPI, covering single-page, multi-page, an explicit result cap, and parameter-to-query mapping.

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

---

Implementation plan

Core changes

• Add a LovdataSearchResult class under src/classes/public/
• Add paging support to the transport layer under src/functions/private/API/
• Add Search-LovdataDocument under src/functions/public/Search/
• Add the Search.md group overview page

Tests

• Add a test for a single-page result
• Add a test for a multi-page result
• Add a test for an explicit result cap
• Add a test for parameter-to-query mapping, including date range and legal source

Documentation

• Add a search example under examples/
• Add the search capability to the README showcase

[MariusStorhaug]

Deferred to the authenticated surface milestone, #15. The endpoints this issue covers all require the X-API-Key header, so nothing here is reachable until the credential store lands.

The first release, #2, is scoped to Lovdata's open, key-free surface only. Nothing in this issue changes; it is sequenced behind the credential store rather than rewritten.