[BUG] Minion side master (in multimaster) setting is not shown as set in the minion conf file

Description
The value for master setting in multimaster setup (list) differs depending on it being called using salt-call or salt <minion>

When using salt from the master to show the master setting on the minion, only the first master in the list is shown. Some other options are even hidden or not available like master_list and master_uri_list (this is less important due it's not something commonly used I guess and can be considered "internals").

But being able to see the actual value for master setting is important.

Here you go a simple state to show the values of the master and other mentioned settings gathered from grains, opts and config module, in which you can see the difference when running it using salt-call from the minion directly and when using salt <minion> from the master

{% set master_options = ['master', 'master_list','master_uri_list' ] %}
show:
  test.configurable_test_state:
    - changes: False
    - result: True
    - comment: |
        GRAIN MASTER:
        {{ grains['master'] }}

        CONFIG.GET
        {%- for master_option in master_options %}
        {{ master_option }}: {{ salt['config.get'](master_option) }}
        {%- endfor %}

        

        OPTS
        {%- for master_option in master_options %}
        {{ master_option }}: {{ opts.get(master_option, 'NOT AVAILABLE') }}
        {%- endfor %}


        CONFIG.ITEMS
        {%- for master_option in master_options %}
        {{ master_option }}: {{ salt['config.items']().get(master_option, 'NOT AVAILABLE') }}
        {%- endfor %}

PS C:\Users\adrian> salt-call state.sls minion.minion_config
local:
----------
          ID: show
    Function: test.configurable_test_state
      Result: True
     Comment: GRAIN MASTER:
              ['172.21.0.10', '172.21.0.11']

              CONFIG.GET
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']



              OPTS
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']


              CONFIG.ITEMS
              master: 172.21.0.10
              master_list: ['172.21.0.10', '172.21.0.11']
              master_uri_list: ['tcp://172.21.0.10:4506', 'tcp://172.21.0.11:4506']
     Started: 01:06:31.167354
    Duration: 0.0 ms
     Changes:

Summary for local
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   0.000 ms

$ salt minion-win-1 state.sls minion.minion_config
minion-win-1:
----------
          ID: show
    Function: test.configurable_test_state
      Result: True
     Comment: GRAIN MASTER:
              172.21.0.10

              CONFIG.GET
              master: 172.21.0.10
              master_list:
              master_uri_list:



              OPTS
              master: 172.21.0.10
              master_list: NOT AVAILABLE
              master_uri_list: NOT AVAILABLE


              CONFIG.ITEMS
              master: 172.21.0.10
              master_list: NOT AVAILABLE
              master_uri_list: NOT AVAILABLE
     Started: 01:06:47.796141
    Duration: 0.0 ms
     Changes:

Summary for minion-win-1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   0.000 ms

I have a workaround using the slsutil module yaml deserializer

{% set file_content = salt['file.read']("C:\\ProgramData\\Salt Project\\Salt\\conf\\minion.d\\minion.conf") %}
{% set file_content_des = salt['slsutil.deserialize']("yaml",file_content) %}
{% set master_config = file_content_des.get('master') %}

Despite the workaround, I think the master setting should be respected and maintained the same from grains, opts, config no matter the call type.

Setup
3006.x
Sample files included in the description.

Steps to Reproduce the behavior
Run the provided state, or even try config.get master using salt-call and salt with the minion set in multimaster

Expected behavior
Master option should be shown as set on the minion conf

Start by running the provided state and comparing config.get, config.items, grains, and opts through salt-call versus salt in a multimaster setup. Trace the configuration handling for the master, master_list, and master_uri_list values. Done means the master option and related values are consistently reported from both call types, with tests covering the behavior.