Build mautrix-discord's double puppet server map from its own variables

`matrix_bridge_mautrix_discord_bridge_double_puppet_server_map_default` was
built from `matrix_bridge_beeper_linkedin_homeserver_domain` and
`..._homeserver_address` - a different role's variables, copy-pasted along with
the expression.

No user is affected today: group_vars/matrix_servers points both roles'
`homeserver_address` at `matrix_addons_homeserver_client_api_url` and both
domains at `matrix_domain`, so the rendered value is identical either way. It
only diverges for someone who overrides beeper-linkedin's homeserver settings,
where mautrix-discord would silently follow them.

It does not survive mautrix-discord being used without beeper-linkedin's
defaults in scope, which is how the Molecule scenario found it: with only the
one role loaded, the template fails on the undefined name. The scenario's
neutralising override is dropped in the same commit, so the expression is now
exercised rather than bypassed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT

roles/custom/matrix-bridge-mautrix-discord/defaults/main.yml

@@ -181,7 +181,7 @@ matrix_bridge_mautrix_discord_bridge_double_puppet_server_map_default: |-
   {{
     {}
     | combine({
-      matrix_bridge_beeper_linkedin_homeserver_domain: matrix_bridge_beeper_linkedin_homeserver_address
+      matrix_bridge_mautrix_discord_homeserver_domain: matrix_bridge_mautrix_discord_homeserver_address
     })
   }}
 matrix_bridge_mautrix_discord_bridge_double_puppet_server_map_auto: {}

roles/custom/matrix-bridge-mautrix-discord/molecule/default/molecule.yml

@@ -71,15 +71,6 @@ provisioner:
         matrix_bridge_mautrix_discord_scheme: http
         matrix_bridge_mautrix_discord_bridge_avatar_proxy_key: molecule_avatar_proxy_key_7c1d
 
-        # The role's default for this references
-        # `matrix_bridge_beeper_linkedin_homeserver_domain` /
-        # `..._homeserver_address`, which belong to a *different* role. In a
-        # playbook run every role's defaults are in scope, so it renders; a role
-        # scenario has only this role loaded and the template fails on the
-        # undefined name. Neutralised here rather than worked around in the
-        # role, and reported as a defect of the role.
-        matrix_bridge_mautrix_discord_bridge_double_puppet_server_map_default: {}
-
         # verify.yml runs as its own play, where role defaults are out of scope,
         # so the paths it reads are pinned here as literals matching what the
         # role derives from matrix_base_data_path.