fix: separate app-name resolution for container creation

[jonasfluegge]

Summary

Fixes #27.

Container creation reused ResolveAppName, which applies a heuristic intended for looking up an existing container: a hyphen in the supplied name is treated as a sign that the name belongs to another user ({otherUsername}-{containerName}), so admins get it used as-is, and non-admins are rejected outright.

That heuristic doesn't apply during creation — there is no existing container to "reference," only a new name the user is choosing. As a result, creating a container whose name itself contained a hyphen (e.g. my-app) either threw an UnauthorizedAccessException for non-admins, or silently skipped the creator's username prefix for admins. Containers created this way weren't recognized as belonging to their creator: they didn't show up in the default container listing (including in the VS Code extension), weren't counted toward the creator's MaxContainers quota, and had their owner mis-parsed wherever the app label is split on the last hyphen.

Change

Adds ResolveNewAppName in FkhServiceBase, used only by FkhCreateContainer. It always applies the creator's own {githubUsername}- prefix unless the supplied name already starts with it, and never interprets an embedded hyphen as a reference to someone else's container.

ResolveAppName itself is unchanged and continues to be used by all operations that reference an existing container (FkhRemoveContainer, FkhScaleContainer, FkhGetContainerDetails, etc.), preserving the intended admin cross-user lookup behavior described in its docstring.

Files changed

• fkh-backend/Services/FkhServiceBase.cs
• fkh-backend/Services/FkhCreateContainer.cs

Notes

This does not retroactively fix containers already created without the correct prefix before this fix — those would need a manual label/migration step if they should be re-associated with their creator.

[freddydk]

FYI
When using fkh CreateContainer from a GitHub workflow, using --useOIDC, the github username becomes "orgname-reponame" (see FunctionBase ~600).
Since you cannot have a github User with the same name as a GitHub organization, this is safe and signalling that the container belongs to the org and only admins (or workflows) can interact with it.
Fix is still fine, since the github username is set here and should work.

[freddydk]

Right now - I am working on fixing versioning, releasing, building etc. so that partners and customers can be using a specifc version (ex. v2026.616.0 - which would be from 2026, June 16th) including pre-release strategy etc.
When that is in place - I will merge this into main, so that I can test these things in preview before rolling out.
Give me a few days.