feat(console): return workspace and user IDs from the Go usage endpoint

[ren-diao]

Issue for this PR

Closes #54283

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds workspaceID and userID to the GET /zen/go/v1/usage response. The handler already looks both up to find the key's Go usage row, so this only returns them. Clients that track several Go subscriptions can then identify a subscription by its owner rather than by the API key, which differs per key and changes on rotation.

This file only serves keys that are not proxied. Migrated workspaces and oc_sk_ keys go to the new inference backend, which would need the same fields.

How did you verify your code works?

Not run: the console needs its database and infrastructure, which I don't have. Both values come from the auth row the handler already selects and has null-checked above. Separately, I confirmed the current response against a live Go key: it contains only usage.

Screenshots / recordings

N/A

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

🤖 Generated with Claude Code

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• Not all checklist items are checked. Please confirm you have tested locally and have not included unrelated changes.

Please edit this PR description to address the above within 72 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[opencode-agent]

Thanks for the PR and the clear write-up, @ren-diao!

The dev branch (v1) only takes critical fixes, such as data loss, security problems or breakage with no workaround. Returning workspaceID and userID from GET /zen/go/v1/usage is a useful addition, but it's a new feature rather than a fix, so I'm closing this PR. The v2 branch doesn't have this Go usage route either, so this change has no direct v2 equivalent to open instead.

The request is still tracked in #54283, where the maintainers can decide how they want to expose these fields, including on the new inference backend you mentioned.