feat(table): Add Keyspace reference for keyspaceName

[gustavodiaz7722]

Adds cross-resource references to 1 top-level field on Table in keyspaces-controller.

Every field here is a top-level spec field (not nested in a struct or list) whose target Kind is confirmed ACK-managed. None needs set: ignore, late_initialize, or skip_resource_state_validations.

Fields Added

#	Field (generator.yaml path)	Target	path
1	Table.KeyspaceName	Keyspace (same-service)	Spec.KeyspaceName

Verification

Deployed this branch to a dev EKS cluster (us-west-2) with ack-workspace deploy keyspaces --resync-period 60 and exercised the references against real AWS resources.

This is the lightweight check: the reference resolves and the resource reaches Synced. It is deliberately not the full pass matrix — no multi-resync delta count and no reference-preservation check — so rows below say nothing about long-run delta behaviour.

#	Reference	RefsResolved	Synced	Concrete absent	*Ref present	Result
1	Table.keyspaceRef	✅	✅	✅	✅	PASS

Summary: 1 PASS of 1.

• Table.keyspaceRef — table created in AWS inside the referenced keyspace

A pre-existing reconcile loop is worth knowing about, though it is not caused by this
change and does not block the reference. The reference itself works: ACK.ReferencesResolved=True,
keyspaceName absent from .spec, keyspaceRef present, and the table was created in AWS
inside the referenced keyspace — a value never supplied literally:

$ aws keyspaces get-table --keyspace-name reftest_ks --table-name reftest_tbl
{"keyspaceName": "reftest_ks", "tableName": "reftest_tbl", "status": "ACTIVE"}

On later reconciles the Table drops to ACK.ResourceSynced=Unknown with
ValidationException: No option is provided to update in the request. The delta driving that
is not on keyspaceRef — it is on server-defaulted fields the user never set:

diff: Spec.CapacitySpecification  A=null B={"throughputMode":"PAY_PER_REQUEST"}
      Spec.Comment                A=null B={"message":""}
      Spec.DefaultTimeToLive      A=null B=0
      Spec.EncryptionSpecification A=null B={"type_":"AWS_OWNED_KMS_KEY"}
      Spec.PointInTimeRecovery    A=null B={"status":...}

I confirmed it is pre-existing with a control: a second Table created with a literal
keyspaceName and no reference at all fails identically. Supplying those five server-defaulted
fields explicitly clears the delta and the reference-backed Table reaches Synced=True, which
is what the PASS above reflects. The control Table, left without them, is still looping — so
the two are cleanly separable: the loop belongs to those unconfigured defaults, not to
keyspaceRef. A separate late_initialize fix on those fields would remove the sharp edge.

What was checked mechanically

• Workspace refreshed (runtime, code-generator, controller) before generating; regenerated with ack-workspace build keyspaces against code-generator v0.62.1.
• A *Ref companion is emitted on the spec for every field above.
• resolveReferenceFor<Field> is emitted for every field above, confirmed by diffing the set of resolver names against main (regeneration reorders the file, so a naive line diff over-reports).
• Fields that were in a CRD required list are relaxed out of it.
• service_name omitted for same-service targets, set for cross-service.
• go build ./cmd/controller passes.
• No new go.mod dependency, so ATTRIBUTION.md is unchanged.

Commit layout

main now carries the code-generator v0.62.1 regeneration (from the auto-generated release PR), and this branch is merged up to date with it, so the Files changed diff is limited to the reference change itself plus the recorded ack-generate stamp. The earlier regeneration commit on this branch is therefore redundant with main and contributes nothing to the diff.

[ack-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gustavodiaz7722

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [gustavodiaz7722]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment