fix: self-heal user identity hash drift

[njf-strike]

Summary

This carries the Obot user-hash self-heal patch in the LN-Zap owned fork instead of relying on upstream Obot to accept or release it.

The patch repairs stale user hash fields during normal identity reconciliation. If an existing user row belongs to the provider identity but has a stale hashed_username or hashed_email, ensureIdentity updates those deterministic hash fields inside the existing transaction. UpdateUser also keeps hashed_username synchronized when username changes.

This draft also adds a fork-owned sandbox image workflow so, after merge, we can publish ghcr.io/ln-zap/obot:sandbox-<commit-sha> without depending on the inherited branch-name image tags.

Why We Own This Patch

The Core AI sandbox recovery path needs this behavior on our timeline. The upstream PR and issue were closed intentionally as not planned for this effort; this fork is the controlled patch surface for the image we deploy.

What Changed

• Repair HashedUsername and HashedEmail for existing users during ensureIdentity.
• Update HashedUsername when UpdateUser changes Username.
• Compare username uniqueness through hashed_username.
• Add regression coverage for auth reconciliation repair and explicit user updates.
• Add a manual sandbox image publisher that emits a lowercase GHCR tag in the required sandbox-<commit-sha> shape.

Validation

go test ./pkg/gateway/client -run 'TestEnsureIdentityRepairsUserHashDrift|TestUpdateUserUpdatesHashedUsername' -count=1
go test ./pkg/gateway/client -count=1
ruby -ryaml -e 'YAML.load_file(".github/workflows/strike-sandbox-image.yml"); puts "workflow_yaml_ok"'

All commands pass locally. Commits b2d9a87e and ac7b842f are signed.

Integration Note

This PR should stay draft until we explicitly decide to merge and publish the fork image. After merge, the resulting main commit becomes the source for ghcr.io/ln-zap/obot:sandbox-<commit-sha>.

The hosted Core AI sandbox image still needs a zap-infrastructure follow-up that consumes that fork image as its Obot base and layers the Okta provider guard on top. Until that image path changes, the deployed provider guard is active but the Obot binary self-heal is not yet in the running image.

[njf-strike]

Ownership decision from the Core AI sandbox recovery path:

• LN-Zap/obot owns the Obot code patch.
• This PR should merge before publishing a fork image.
• The fork image tag shape should be sandbox-<commit-sha>.
• zap-ai owns live contract/evidence checks for the sandbox behavior.
• zap-infrastructure should consume the published fork image as the OBOT_BASE_IMAGE for the final obot-oss-okta-provider image, not rebuild Obot source itself.

This keeps the patch owned and reviewable here, while leaving image assembly and environment pinning in the existing infra/GitOps pipeline.

[njf-strike]

Release gate decision: keep this PR as the fork-code review. After it merges, publish the fork image from the merged commit with tag shape sandbox-<commit-sha>. zap-infrastructure then consumes that image as the base for the final provider image.

[njf-strike]

Closing this public linked-fork PR as superseded. The active path is now the private detached repo PR: LN-Zap/obot-core-ai#1. The release image should come from ghcr.io/ln-zap/obot-core-ai:sandbox-, then zap-infrastructure layers the Okta provider assets and publishes the final deployable image. No merge or image publication should happen from this public fork path.