fix(auth): workspace owner can generate token via read_write token (#958)

[oeway]

Summary

Fixes the remaining half of #958. A workspace owner cannot generate a token
for their own workspace when the token they are acting through only grants
read_write — they hit PermissionError("Only admin can generate token."). In
practice this blocks a normal user from starting their own server-app: apps.start
calls workspace.generate_token, and Svamp's stored/derived token for the user's
own workspace is a child read_write token.

#959 (already merged) fixed the scope-shadowing half — get_permission now
returns the strongest of * and the specific-workspace grant. This PR fixes the
ownership-recognition half so the two together let an owner start their own
server-apps without an admin token.

Root cause

generate_token() only ran its owner-elevation fallback when the resolved
permission was falsy:

maximum_permission = user_info.get_permission(allowed_workspace)
if not maximum_permission:                     # <-- only None triggers the fallback
    workspace_info = await self.load_workspace_info(allowed_workspace)
    if workspace_info.owned_by(user_info):
        maximum_permission = UserPermission.admin
    else:
        raise PermissionError("You do not have any permission ...")
if maximum_permission != UserPermission.admin:
    raise PermissionError("Only admin can generate token.")

An owner acting through a read_write token has maximum_permission == read_write,
skips the fallback entirely, and hits "Only admin can generate token."

There is a second, related gap. A child token minted via generate_token() gets
a fresh random id and carries parent = <original user id>, but owned_by() only
matched on id/email being present in the workspace owners list. A personal
workspace ws-user-<uid> does not necessarily materialise the email in owners, so
owned_by() returned False for the user's own child token even though it is the
same user.

Changes

1. WorkspaceInfo.owned_by() also recognises a user's personal workspace by
   construction — ws-user-<user.id>, and ws-user-<user.parent> for a child token.
   The parent chain is assigned server-side inside generate_token() and is not
   settable by a caller, so this cannot be forged. This makes ownership recognition
   consistent with how personal workspaces are keyed, independent of what is
   materialised in owners.

2. generate_token() runs the ownership fallback whenever the resolved
   permission is below admin (not only when it is None). A non-owner with no
   permission at all still gets the original "no permission" error; a non-owner with
   read_write still gets "Only admin can generate token."

Test

Adds test_owner_can_generate_token_with_read_write_token: an owner connects,
mints a read_write token, reconnects with it, and mints a further token for their
own workspace — which raised "Only admin can generate token" before this change.

Notes

This is currently applied in production as a runtime monkeypatch (the amun-ai
platform's hypha-fix958 launcher, "owner-elevation" patch); merging this lets us
drop that patch. No behavior change for non-owners.
🤖 Generated with Claude Code