Workfront Planning `createRecord` Fusion module — linked fields still require raw field IDs

Summary:
The native `workfront-maestro:createRecord` Fusion module does not fully abstract field IDs for linked/connection fields (many-to-many relationships), despite Workspace and Record Type being correctly selected by label from the UI.

Expected behavior:
The native module should handle the internal field key mapping automatically — developers should never need to know or use raw field IDs like `F69d64ac7f0097169d4b252c8` or construct objects with `_id` suffixed keys like `{"F69d64ac7f0097169d4b252c8_id": "Rc69..."}` manually.

Actual behavior:
For linked/connection fields, the module exposes `fieldID_id` suffixed keys in the nested object spec. Developers must manually construct payloads like:
`[{"F69d64ac7f0097169d4b252c8_id": "Rc69..."}]`

This defeats the primary value proposition of the native module over a Custom API Call, which is to abstract away raw field and record IDs.

Impact:
Teams building automations with linked fields are forced to hardcode field IDs into their Fusion scenarios, making scenarios brittle and hard to maintain across environments (DEV/Stage/Prod).

Request:
Please update the `createRecord` module to fully resolve linked field specs by label, and handle the `_id` key mapping internally — the same way simple text, date, and select fields are already handled.