Packer: getting validation errors on multi-line strings

Question

I am trying to build templates with packer against Proxmox using proxmox-iso. I am running packer version 1.9.4. I have the following group of local vars in my build file:

locals {
  </snip>
  data_source_content = {
    "/meta-data" = file("${abspath(path.root)}/data/meta-data")
    "/user-data" = templatefile("${abspath(path.root)}/data/user-data.pkrtpl.hcl", {
      build_username           = "${var.build_username}"
      build_password           = "${var.build_password}"
      build_password_encrypted = "${var.build_password_encrypted}"
      vm_os_language           = "${var.vm_os_language}"
      vm_os_keyboard           = "${var.vm_os_keyboard}"
      vm_os_timezone           = "${var.vm_os_timezone}"
    })
  }
}

When I try to validate this template, I get the following error:

Error: Error in function call

  on builds/linux/<sensitive>/22-04-lts/linux-<sensitive>-proxmox.pkr.hcl line 38:
  (source code not available)

with path.root as "builds/linux/<sensitive>/22-04-lts/",
     var.build_password as "<sensitive>",
     var.build_password_encrypted as "<sensitive>",
     var.build_username as "<sensitive>",
     var.vm_os_keyboard as "us",
     var.vm_os_language as "en_US",
     var.vm_os_timezone as "UTC".

Call to function "templatefile" failed:
/home/ubuntu/proxmox-devops/builds/linux/<sensitive>/22-04-lts/data/user-data.pkrtpl.hcl:16,35-17,1:
Invalid multi-line string; Quoted strings may not be split over multiple lines.
To produce a multi-line string, either use the \n escape to represent a newline
character or use the "heredoc" multi-line template syntax., and 249 other
diagnostic(s).

I tried to use a heredoc but I don't think I did it right since I still get a validation error. Also, I don't know if a heredoc is appropriate for this variable type. I have tried a few different ways to format the variables. The weird thing is that when I take the sensitive parameter off of some of the vars and I try to validate the templates I see the usernames and passwords in the output. So to me that means the variables are being set and passed down to the template properly. So this really seems like a formatting issue.

Does anyone know how I should format the data_source_context variable above?

EDIT: As requested, here is the user-data.pkrtpl.hcl:

#cloud-config
autoinstall:
  version: 1
  early-commands:
    - sudo systemctl stop ssh
  locale: ${vm_os_language}
  keyboard:
    layout: ${vm_os_keyboard}
  storage:
    config:
%{ if "${vm_firmware} == "ovmf" ~}
      - ptable: gpt
        path: /dev/sda
        wipe: superblock
        preserve: false
        grub_device: true
        type: disk
        id: disk-sda
      - device: disk-sda
        size: 1M
        flag: bios_grub
        number: 1
        preserve: false
        type: partition
        id: partition-grub
%{ else ~}
      - ptable: gpt
        path: /dev/sda
        wipe: superblock
        preserve: false
        type: disk
        id: disk-sda

      - device: disk-sda
        size: 768M
        wipe: superblock
        flag: boot
        number: 1
        preserve: false
        grub_device: true
        type: partition
        id: partition-efi

      - fstype: fat32
        volume: partition-efi
        preserve: false
        type: format
        id: fs-efi
        label: EFI
      - path: /boot/efi
        device: fs-efi
        type: mount
        id: mount-efi
%{ endif ~}
<bunch of partitions and lvols>
  identity:
    hostname: ubuntu-server
    username: ${build_username}
    password: ${build_password_encrypted}
  ssh:
    install-server: true
    allow-pw: true
  packages:
    - openssh-server
    - qemu-guest-agent
    - cloud-init
  user-data:
    disable_root: false
    timezone: ${vm_os_timezone}
  late-commands:
    - sed -i -e 's/^#\?PasswordAuthentication.*/PasswordAuthentication yes/g' /target/etc/ssh/sshd_config
    - echo '${build_username} ALL=(ALL) NOPASSWD:ALL' > /target/etc/sudoers.d/${build_username}
    - curtin in-target --target=/target -- chmod 440 /etc/sudoers.d/${build_username}