xmpp.js config (cannot get messages across bridge)

I've been working on getting xmpp.js working with matrix-bifrost. I've managed to get it talking to my synapse server and connected to the prosody component (per the logs) but messages aren't flowing between xmpp and matrix via xmpp.js. From what I can tell the account isn't showing online on the prosody side despite the bridge being connected to the external component.

Below is my registration.yaml and config.yaml with the secrets/domain redacted. Otherwise this is exactly what I have running on my server.

Any help would be appreciated.

status when asking the bot about accounts linked

Linked accounts:
    XMPP.js Protocol Plugin (test2@xmpp.domain.tld) [Enabled=true] [Connected=true]

registration.yaml

id: [redacted]
hs_token: [redacted]
as_token: [redacted]
namespaces:
  users:
    - exclusive: true
      regex: '@_bifrost_.*'
  aliases:
    - exclusive: true
      regex: '#_bifrost_.*'
  rooms: []
url: 'http://localhost:9555'
sender_localpart: _bifrost_bot
rate_limited: true
protocols: null

config.yaml

bridge:
  # Your homeserver server_name.
  domain: "domain.tld"
  # A internally reachable endpoint for the CS api of the homeserver.
  homeserverUrl: "https://matrix.domain.tld"
  # Prefix of all users of the bridge.
  userPrefix: "_bifrost_"
  # If homeserverUrl is not reachable publically, the public address that media can be reached on.
  # mediaserverUrl: "http://example.com:8008"
  # Set this to the port you want the bridge to listen on.
  appservicePort: 9555

datastore:
  # The datastore engine to use, either "nedb" or "postgres"
  engine: "nedb"
  # For NeDB:
  #   Location of the user and room database files, by default will be stored in the working directory.
  # For Postgres:
  #   A postgres style connection string, e.g. "postgres://postgres:pass@localhost/bifrost"
  connectionString: "nedb:///data/nedb"

purple:
  # For selecting a specific backend. One of "node-purple", "xmpp.js". Defaults to "node-purple"
  backend: "xmpp-js"
  enableDebug: true
# -- For xmpp.js - You need an existing xmpp server for this to work.
  backendOpts:
    # endpoint to reach the component on. The default port is 5347
    service: "xmpp://127.0.0.1:5347"
    # domin assigned to the component.
    domain: "matrix-bifrost.xmpp.domain.tld"
    # password needed by the component.
    password: "redacted"

# Matrix forwards room aliases join requests matching a regex in the
# registration file to the owner's bridge, if the room doesn't exist.
# The following options allow you to configure how the purple bridge may
# match those aliases to remote rooms.
portals:
  # Enable gateway support for protocols that support them, e.g. xmpp.js
  enableGateway: true
  # List of regexes to match a alias that can be turned into a bridge.
  aliases:
    # This matches _purple_ followed by anything
    "/^_bifrost_(.+)$/":
      # Use the prpl-jabber protocol.
      protocol: "prpl-jabber"
      properties:
        # Set room to the first regex match
        room: "regex:1"
        # Set the server to be conf.localhost
        server: "xmpp.domain.tld"
    # For xmpp.js, please use:

# Automatically register users with accounts if they join/get invited
# a room with a protocol they are not bound to.
# This is REQUIRED for xmpp.js to work.
autoRegistration:
  enabled: true
  protocolSteps:
# For xmpp.js, please use:
  xmpp-js:
    type: "implicit"
    parameters:
      username: "<T_LOCALPART>@xmpp.domain.tld"

# Set up access controls for the bridge
access:
  accountCreation:
    whitelist:
      - "^@me:domain.tld$"

# Available subsitution variables for parameters:
# <T_MXID> - The users mxid.
# <T_MXID_SANE> - The users mxid, with an : replaced with _ and the @ discarded.
# <T_DOMAIN> - The users domain.
# <T_LOCALPART> - The users localpart.
# <T_DISPLAYNAME> - The users displayname, or localpart if not set.
# <T_GENERATEPWD> - Generates a 32 char password
# <T_AVATAR> - The MXC url of the users avatar, if available.


## This is how to autoregister folks with prosody (xmpp)
## with the included lua script in extras. This applies to node-purple (NOT xmpp.js)
#   protocolSteps:
#       prpl-jabber:
#           type: "http"
#           path: "http://localhost:5280/register_account/"
#           opts:
#               method: "post"
#               usernameResult: null
#           parameters:
#               username: "m_<T_LOCALPART>"
#               nick: "<T_DISPLAYNAME>"
#               password: "<T_GENERATEPWD>"
#               auth_token: "bridge-token"
#               ip: "127.0.0.1"
#           paramsToStore:
#               - password

# Enable prometheus metrics reporting.
# This will report metrics on /metrics on the same port as the bridge.
metrics:
  enabled: true

provisioning:
  # Can users use ""!purple" in a room to bridge it to a group.
  enablePlumbing: false
  # Required power level to bridge a room into a group.
  requiredUserPL: 100

logging:
  # Set the logging level for stdout.
  # Lower levels are inclusive of higher levels e.g. info will contain warn and error logging.
  console: "debug" # "debug", "info", "warn", "error", "off"
  # A list of files and their associated logging levels.
  files:
    "/data/info.log": "info"
    "/data/error.log": "error"
    "/data/warn.log": "warn"
    "/data/debug.log": "debug"

# These are specific flags or values to tune the bridge to different setups.
# The defaults are usually fine, but adjust as needed.
tuning:
    # Do not send a message or join a room before setting a users profile for
    # the first time. This should help clients hide ugly mxids better behind
    # displaynames.
    waitOnProfileBeforeSend: true
    #  A nasty hack to check the domain for conf* to see if the PM is coming from a MUC.
    # This is only really needed for legacy clients that don't implement xmlns.
    # This is specific to the XMPP.js bridge.
    # conferencePMFallbackCheck: false
    # Don't send messages from the remote protocol until we have seen them join.
    # A list of prefixes to check for a userId.
    # This is useful for talking to remote IRC users who might not see a message
    # until after they have joined.
    #waitOnJoinBeforePM: string[];

Start with the supplied config.yaml and registration.yaml, then inspect the bridge debug logs and the Prosody component status to trace account presence and message routing. Done means identifying the configuration or integration fault and confirming messages flow in both directions between XMPP and Matrix.