[fix][core] stop returning credentials from the current user endpoint (24.05)

[ar2rsawseen]

Backport of #7939 to release.24.05.

What

/o/users/me returned the caller's member document with only the password removed:

usersApi.getCurrentUser = function(params) {
    delete params.member.password;
    common.returnOutput(params, params.member);

So the response carried the account's api_key, and for members using two factor auth the stored secret for that factor as well. The neighbouring reads already treat both as sensitive: getUserById and getAllUsers project api_key away, and the member event payloads delete it with a comment saying it must never be forwarded. This was the one read path that handed it out.

Separately, a token that was restricted to specific applications could reach this endpoint. The restriction in verify_token is only compared when the request itself names an application, and this request never does, so the restriction was not applied.

Change

1. Answer with a copy of the member that has password, api_key and two_factor_auth removed. A copy, so nothing later in the request sees a mutated member.
2. Refuse a token restricted to specific applications on this endpoint. It reports the caller's own account and belongs to no application, so an application restricted token has no business reading it.

Tokens with no application restriction behave exactly as before.

Why this is safe to change

• Nothing in the product reads the key from here. The dashboard takes api_key from the server rendered globals, and there is a dedicated /api-key route for a member who wants their own key. No frontend code calls /o/users/me at all.
• No test expects the key. The existing assertions on this endpoint check email, full_name, global_admin and username.
• The existing token suites still pass by construction. The token used against /o/users/me in test/2.api/14.authorize.token.js is created with no app, so it is unrestricted and unaffected. The token in App-scoped token enforces its app restriction is pinned to ^/o/actions, so it never reaches this endpoint either.
• two_factor_auth.enabled remains available where the UI actually reads it, from the user listing.

Verification

Two cases added:

• test/2.api/02.read.user.js: the response still carries the account's own fields but has no api_key, no password and no two_factor_auth.
• test/2.api/14.authorize.token.js: a token restricted to one application, with no endpoint restriction, is refused on /o/users/me. This is a different token shape from the existing app restriction case, which is endpoint pinned.

Lint and node --check clean on all changed files.