fix(types): correct three return types in ApiRocketChat that describe the wrong value

[diegolmello]

Problem

Three members of lib/api/RocketChat.ts have declared types that do not describe what they return.

1. getRoomIdByNameOrId claims to resolve a room id, but resolves the whole response body:

getRoomIdByNameOrId (name: string): Promise<RID> { return this.get('chat.getRoomIdByNameOrId', { name }, true) }

Every sibling helper unwraps its response (.room, .channel, .message, .name). This one does not, so callers typed against RID receive an object. Compare getRoomName, right below it, which does unwrap via .name.

2 and 3. channelInfo and privateInfo cast an already-awaited value to a Promise:

async channelInfo (query: { roomName?: string, roomId?: string }) {
  return (await this.get('channels.info', query, true)).channel as Promise<IChannelAPI>
}

The await has already resolved, so .channel is an IChannelAPI, not a Promise<IChannelAPI>. Because the method is async, the declared return type becomes Promise<Promise<IChannelAPI>> — which collapses at the call site and so hides the mistake rather than reporting it. privateInfo has the identical shape with IGroupAPI.

Steps to reproduce

• Call getRoomIdByNameOrId and inspect the resolved value against its Promise<RID> signature
• Hover channelInfo's return type and observe the nested promise

Proposed fix

For getRoomIdByNameOrId: decide whether it should unwrap to an id (matching both its name and its signature) or whether the signature should describe the body. Unwrapping is the consistent choice, but it is a behaviour change for any current caller, so check the consuming app first.

For channelInfo / privateInfo: drop the as Promise<...> casts and annotate the unwrapped type directly.

Note for whoever picks this up: pin the current runtime behaviour with tests first, then change the types — do not write a test that asserts the present shape is correct beyond recording what it is.