`unregisterChannel()` never unregisters a channel

Version: current master at 0ebdd5120eca8840e3ffd6597cd4e83732b59c9a (minecraft-protocol 1.68.0)

unregisterChannel() uses Array.find() and stores the matching channel name in index, then passes that string to splice():

const index = channels.find(name => channel === name)
if (index) {
  proto.types[channel] = undefined
  channels.splice(index, 1)
}

JavaScript coerces a non-numeric channel string to 0, so unregistering any custom channel removes the first registered channel instead of the requested channel. Since the two built-in register/unregister channels are added first, the custom channel remains active.

Minimal reproduction:

const EventEmitter = require('events')
const inject = require('./src/client/pluginChannels')
const client = new EventEmitter()
client.write = () => {}
inject(client, { version: '1.21.4' })

client.registerChannel('example:first')
client.registerChannel('example:second')
client.on('example:second', () => console.log('still active'))
client.unregisterChannel('example:second')
client.emit('custom_payload', { channel: 'example:second', data: Buffer.alloc(0) })

Actual: prints still active.

Expected: the listener should not be reached through custom_payload after the channel is unregistered.

The lookup should likely use findIndex() instead of find() and check index !== -1.

Relevant code: https://github.com/PrismarineJS/node-minecraft-protocol/blob/0ebdd5120eca8840e3ffd6597cd4e83732b59c9a/src/client/pluginChannels.js#L37-L49

Start in src/client/pluginChannels.js around lines 37-49 and run the minimal reproduction from the issue. Verify that unregistering example:second no longer reaches its listener through custom_payload, and add or update coverage for this behavior if the repository's existing tests provide a suitable location.