`record.subMap` can return either a `RecordMap` or a `LinkedHashMap` depending on key input

Bug report

The record.subMap method accepts a key iterable with the expectation that a record is returned. However, this is only the case if the keys are enclosed in [..]. In the event that it is not provided as a list, the type is silently converted to a LinkedHashMap.

Expected behavior and actual behavior

nextflow.enable.types = true

workflow {
	main:

	def records: Channel<Record> = channel.of(record(id: "example", value: "value1"))

	records.map{ r: Record ->
		def subMapFromList: Record = r.subMap(["id"])
		def subMapFromString: Record = r.subMap("id")

		println("subMap(['id'])  -> value: ${subMapFromList}, type: ${subMapFromList.getClass()}")
		println("subMap('id')    -> value: ${subMapFromString}, type: ${subMapFromString.getClass()}")
	}

}

In the above code, the first output is the expected behavior. Keys provided in the subMap call for a record return a record as the output.

The 2nd output shows the actual behavior when subMap is provided a key / set of keys outside of a list. Instead of returning a record, this is silently converted to a LinkedHashMap.

Steps to reproduce the problem

See above.

Program output

 N E X T F L O W   ~  version 26.04.6

Launching `tmp.nf` [gloomy_minsky] revision: 6cce971aed

WARN: Static typing is a preview feature -- syntax and behavior may change in future releases
subMap(['id'])  -> value: [id:example], type: class nextflow.util.RecordMap
subMap('id')    -> value: [id:example], type: class java.util.LinkedHashMap

Environment

• Nextflow version: 26.04.6
• Java version: openjdk 17
• Operating system: Linux
• Bash version: zsh 5.8.1 (x86_64-ubuntu-linux-gnu)

Start with the reproducer in the issue and inspect the implementation of record.subMap and the RecordMap type, comparing calls with a list key and a string key. Done means both forms return a RecordMap-compatible record with the same selected values, with coverage for the two key-input cases.