Add project data source

[IlyaasK]

What changed

• Add the read-only kernel_project data source.
• Register kernel_project with the provider.
• Add a narrow durable kernelclient.ListProjectPage wrapper for org-scoped project list pagination.
• Keep Terraform exact-name, zero-match, and ambiguous-match policy inside internal/datasources/project.
• Validate required project response fields before writing Terraform state.

Intentionally unsupported

• No kernel_profile, kernel_proxy, or kernel_extension data sources in this PR.
• No browser/session runtime operations: acquire, release, flush, logs, screenshots, live view, recovery, or force-release.
• No resource mutation behavior in the project data source.

Tests run

• GOCACHE=/private/tmp/terraform-provider-kernel-go-cache go test ./internal/datasources/project ./internal/kernelclient ./internal/provider
• GOCACHE=/private/tmp/terraform-provider-kernel-go-cache go test ./...
• GOCACHE=/private/tmp/terraform-provider-kernel-go-cache go vet ./...
• git diff --check browser-pool-import..HEAD

Review gates

All five review gates passed after fixes:

• deslop
• autoreview
• thermo-nuclear-code-quality-review
• dave-cheney-go-review
• eblog-code-review

---

Note

Low Risk
Read-only Terraform data source and org-scoped list pagination; no resource mutations or auth changes.

Overview
Adds the read-only kernel_project data source so Terraform can look up project metadata by id, exact name, or the provider’s default project_id.

Name lookup paginates through org project lists via a new ListProjectPage client wrapper that reads X-Next-Offset and rejects non-advancing pagination. The data source enforces mutual exclusion of id/name, zero/ambiguous exact-name matches, and validates required API fields (via SDK JSON metadata) before writing state.

The provider registers kernel_project as its first data source; unit tests cover the data source, client pagination, and provider registration.

^{Reviewed by Cursor Bugbot for commit 7c0b29f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

PRs in the kernel, infra, hypeman, and hypeship repos. kernel is a ~mono repo with many logical services underneath, ensure to focus on the implicated service for the PR

Reason: PR repository cannot be determined from provided information; please specify which repo (kernel, infra, hypeman, or hypeship) this PR is in, or manually opt in to deploy monitoring.

To monitor this PR anyway, reply with @firetiger monitor this.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ef1bca7. Configure here.}

[cursor]

Unknown selector blocks known sibling

Medium Severity

resolveProjectSelector rejects the read when either id or name is unknown, even if the other selector is a known non-empty value. A config with a fixed id and an unknown name (or the reverse) fails with “Unknown Project Selector” instead of using the known selector for GetProject or name lookup.

 

^{Reviewed by Cursor Bugbot for commit ef1bca7. Configure here.}

[IlyaasK]

Won't fix — intentional. Terraform core defers data-source reads to apply time while config values are unknown, so Read seeing an unknown here is a defensive shouldn't-happen guard, and failing loud is the safe response. Honoring the known sibling would also be wrong: if id is known and name is configured-but-unknown, both selectors are configured, so the config must fail the only-one-of conflict check once name resolves — reading with just id would mask a config that has to be rejected anyway. (This helper is replaced by the shared datasources.ResolveIDNameSelector in #14 with the same semantics.)

[cursor]

Ambiguity counts duplicate rows

Low Severity

Name lookup increments count for every list row whose name equals the query string, without deduplicating by project id. If pagination or the API returns the same project more than once, the data source can report an ambiguous name when only one distinct project exists.

 

^{Reviewed by Cursor Bugbot for commit ef1bca7. Configure here.}

[IlyaasK]

Fixed (via the stack): the project scan this points at is deleted in #14 (name lookup becomes a single server-resolved GetProject(name), no counting at all). The same hazard in the profile (#14) and proxy (#15) scans is fixed directly: matches are now deduplicated by id before counting, so a row repeated by offset-pagination skew is one match, not a false ambiguity (commits b97c471 / 88fbea9, with TestReadDeduplicatesRepeated{Profile,Proxy}LookupRows).

[tnsardesai]

reviewed — solid PR overall. one thing worth a look:

Possible bug

• internal/datasources/project/datasource.go:210 — name validation runs on every project in the page before the project.Name != name filter, so one unrelated project with a malformed/empty name (returned by the fuzzy query) aborts the whole lookup even when a valid exact match exists. consider validating only after the name matches, or skipping (not erroring on) invalid non-matches.

[IlyaasK]

Thanks @tnsardesai — valid finding, and it ended up improving two other data sources.

For kernel_project specifically: not fixed in this PR because the flagged code is deleted one PR up the stack — #14 removes findProjectsByName/ListProjectPage entirely and switches name lookup to a single server-resolved GetProject(name) (the API resolves the GET path param by id-or-name since project names are unique per org, kernel/kernel#2455). No list scan means no unrelated rows to trip over, so the failure mode you describe can't ship.

But the same pattern survived in the profile (#14) and proxy (#15) scans in a narrower form: rows with absent names were already skipped, but a row with a present-yet-inconsistent raw name JSON still aborted the whole lookup even when it wasn't the requested name — worst for kernel_proxy, whose list has no server-side name filter at all (proxy names aren't unique), so one corrupt unrelated row would brick every name lookup in the project. Fixed both exactly as you suggested: filter on the decoded name first, and run the raw-consistency validation only on rows that claim the requested name (still fail-loud there — a corrupt row we'd actually return is a broken API response). Pinned with TestReadSkipsMalformedUnrelatedProfileLookupRows / TestReadSkipsMalformedUnrelatedProxyLookupRows, plus repurposed the old invalid-candidate tests to assert the fail-loud-on-match behavior.

Heads: #14 9bac0d1, #15 9e373f4. go vet ./... + full datasource tests green on every open branch in the stack.