feat: use newest Hub modules for STACKIT

[Jelledb]

This should fix custom metering not working moving forward

[grubmeshi]

Taking this over. Rebased on main (which had moved on to ce25ec5) and pushed two commits.

The bump could not land as written

a93aba0 has no reference-architectures/stackit-sandbox-landingzone. 0ef0fdd merged it with stackit-hub-spoke into one stackit-landingzone that takes an optional network. tofu init fails with subdir "reference-architectures/stackit-sandbox-landingzone" not found, so the source path had to move too.

The rename shipped without moved blocks

Three resources change address between 942edaf and a93aba0, and the hub had no moved blocks for any of them. None of them live in this repo's state — they belong to the building block run, whose state meshStack holds — so tofu state mv here was not an option.

Old address	New address	What a replacement costs
stackit_resourcemanager_project.backplane	…project.foundation	Holds the project-creation service account. module.backplane keys it on the project id, and every tenant project names it as owner_email.
…meshstack_landingzone.stackit_default	…meshstack_landingzone.this["default"]	Tenants are assigned to it, and metadata.name is unchanged, so destroy and create collide on the same name.
…meshstack_building_block_definition.this	…this["default"]	Every tenant project building block instantiates it.

meshcloud/meshstack-hub#256 adds the moved blocks. This PR now pins f656771 from that branch instead of a93aba0. Re-pin to the merged main commit once #256 lands.

Plan against live state

Plan: 0 to add, 2 to change, 0 to destroy.
  # meshstack_building_block.stackit_sandbox_landingzone will be updated in-place
  # module.stackit_sandbox_landingzone.meshstack_building_block_definition.this will be updated in-place

Planned with a clean terragrunt cache and no provider dev override. The lock file needs no change.

Note that the building block instance also carries the role_mapping change (admin owner → editor) from 41a82cc, which was committed but never applied. That change is already pending on main today, independent of this PR.

Not applied — the apply and the building block run still need watching, because the moved blocks only take effect inside that run.

[grubmeshi]

Checked the role mapping from 41a82cc with stackit project role list against the trial-metering project. The cap on editor is worth keeping, but the reason written in the comment was wrong, so 3d7caf4 rewrites it.

editor can delete the project just like owner

Both roles carry resource-manager.project.delete. Capping admins at editor does not stop a tenant from deleting the project out from under meshStack. Only reader lacks the permission, and reader is no use to someone meant to build in the project.

Role	Permissions	Has resource-manager.project.delete
reader	349	no
editor	809	yes
owner	842	yes

What the cap does buy

owner holds 33 permissions editor does not. The ones that matter here are iam.member.add, iam.member.remove, iam.role.add, iam.role.edit, iam.role.remove and the per-product role-binding permissions (vpc.role-binding.*, secrets-manager.*.role-binding.*, data-catalog.instance.policy.administer).

Without them a tenant cannot grant STACKIT access to people meshStack does not know about. That matters because stackit_authorization_project_role_assignment in the project building block is a for_each over meshStack's own project members only, so an assignment made by hand is invisible to it and survives every later run.

The remainder of the 33 are incidental: argus.grafana.*administrate, mailout.sending-domain.*, postgres-flex.instance.force-delete, mongodb-flex.project.delete, telemetry-link.instance.*, support.assume-role.*, model-experiments.instance.login, sqlserver-flex.instance.protect.

Two things to be aware of

role_mapping is a STATIC input on the STACKIT Project definition, in both the old and the new hub ref. It is not a default tenants can override, so every existing tenant picks the new value up on its next run: each admin's alice@example.com:owner assignment is destroyed and alice@example.com:editor created. No project or resource is touched, but current trial admins are demoted.

After the change admin and user both map to editor, so the two meshStack roles are indistinguishable inside STACKIT.

If protecting the project from deletion is actually wanted, this mapping is not the lever. resource-manager.lock.* is in editor too, so a tenant could remove a lock as easily as set one. It would need a custom STACKIT role.

Plan is unchanged: 0 to add, 2 to change, 0 to destroy.