feat(ske): support audit log configuration

[tobias-pfaffelmoser-ske]

Description

Adds support for configuring SKE cluster audit log forwarding via a new optional
audit block on the stackit_ske_cluster resource (and as a read-only attribute
on the data source):

resource "stackit_ske_cluster" "example" {
  # ...
  audit = {
    enabled = true
  }
}

The audit.enabled flag is passed through to the SKE API (ske.Audit) on create/update and mapped back into state on read. This feature is in private preview and can only be enabled for accounts/projects that have been enabled for audit log forwarding to a Telemetry Router.

This also bumps the stackit-sdk-go/services/ske dependency to v1.19.0, which introduces the audit field.

Acceptance tests are intentionally omitted: audit log forwarding is a private-preview feature that requires account/project enablement, which might not be available in the standard CI test project. The change is covered by unit tests (toAuditPayload, mapAudit) and both K8s create and update were verified manually against a preview-enabled OnDemand QA project.

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see examples/ directory)
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Acceptance tests got implemented or updated (see e.g. here)
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

[rubenhoenle]

I don't fully get this, can't the API just include false in the response in that case?

{
    ...
    "audit": {
        "enabled": false
    }
}

Else you might have users which will run into state drifts: When Terraform users set audit.enabled to false in their Terraform configuration, Terraform will also send false to the API. From my current understanding the API then just won't return the audit object at all in the response. This will lead to Terraform setting audit.enabled to null here which will then result in a state drift error.

[tobias-pfaffelmoser-ske]

Good point.

Just checked with the team: when the feature is available in the respective region, the API always echoes the audit object back, including { "enabled": false }. So setting audit.enabled = false returns enabled: false and maps cleanly back into state - so no drift expected in this scenario.

When the feature is not available in the respective region, the API omits the audit object entirely. That is the situation where cl.Audit == nil, and in that case, audit shouldn't be configured on the cluster in the first place. Mapping it to null might make sense: if a user tries to configure audit in a region without the feature, the resulting diff could be the desired signal that the configuration has no effect at all. WDYT?