fix(api_key): support organization-level NRNs in nrn_without_namespace

[serialito74]

Problem

nullplatform/api_key computes:

nrn_without_namespace = var.nrn != null ? join(":", slice(split(":", var.nrn), 0, 2)) : null

The unconditional slice(..., 0, 2) assumes the NRN always has at least two segments (organization=X:account=Y). When the module receives an organization-level NRN (organization=X, a single segment), the plan fails with:

Error: Invalid value for "end_index" parameter: end index must not be greater than the length of the list.

This blocks using api_key-based modules (e.g. cloud/orchestration configs, agent associations) at the organization level, which is a supported pattern for multi-account NRN inheritance.

Fix

Clamp the slice end to the number of available segments:

nrn_segments          = var.nrn != null ? split(":", var.nrn) : []
nrn_without_namespace = var.nrn != null ? join(":", slice(local.nrn_segments, 0, min(2, length(local.nrn_segments)))) : null

Behavior is unchanged for NRNs with two or more segments; organization-only NRNs now resolve to the organization NRN itself instead of crashing.

Testing

Verified against a real nullplatform organization on Azure/AKS, using a root module that consumes api_key-based modules with an organization-level NRN (organization=<id>):

• Reproduced the failure first on the unpatched module: tofu plan fails with Invalid value for "end_index" parameter as soon as the org-level NRN reaches nrn_without_namespace.
• With this patch applied, tofu plan and tofu apply complete successfully: the api_key resource is created and the agent association works with organization-scoped grants.
• Regression check with a two-segment NRN (organization=X:account=Y): nrn_without_namespace output is byte-identical to the current behavior, so existing consumers see no diff.
• tofu validate and tofu fmt -check clean on the module.