[BUG] specifying grains in the minion config file prevents default grains from being used in pillars

Description
By defining grains directly in the configuration file of a minion as it seems to be allowed the rendering of pillars that use any default grain (ie. os, kernel, ...) will fail.

Setup
(Please provide relevant configs and/or SLS files (be sure to remove sensitive info. There is no general set-up of Salt.)

Please be as specific as possible and give set-up details.

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Steps to Reproduce the behavior
Add the following lines to the minion:

grains:
  roles:
    - testing

Restart the minion: systemctl restart salt-minion

On salt master check that grains.items is returning all grains:
salt 'testing*' grains.items | grep -A4 -B4 roles

        - 9
        - 2
        - final
        - 0
    roles:
        - testing
    saltpath:
        /usr/lib/python3/dist-packages/salt
    saltversion:

Have a pillar that use a default grain ie. in default_user.sls that is included in top.sls pillar :

users:
  root:
    home: /root
    {% if grains.kernel == "FreeBSD" %}
    group: wheel
    {% elif grains.kernel == "Linux" %}
    group: root
    {% else %}
    group: root
    {% endif %}

Then try to apply highstate: salt 'testing*' state.apply test=TRUE

And get the message:

testing:
    Data failed to compile:
----------
    Pillar failed to render with the following messages:
----------
    Rendering SLS 'default_user' failed. Please see master log for details.

And in the logs:

2022-12-04 23:32:18,800 [salt.utils.templates:274 ][ERROR   ][116642] Rendering exception occurred
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 501, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 4, in top-level template code
jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'kernel'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 261, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 508, in render_jinja_tmpl
    raise SaltRenderError("Jinja variable {}{}".format(exc, out), buf=tmplstr)
salt.exceptions.SaltRenderError: Jinja variable 'dict object' has no attribute 'kernel'
2022-12-04 23:32:18,802 [salt.pillar      :888 ][CRITICAL][116642] Rendering SLS 'default_user' failed, render error:
Jinja variable 'dict object' has no attribute 'kernel'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 501, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 4, in top-level template code
jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'kernel'

2022-12-04 23:32:18,918 [salt.pillar      :1208][CRITICAL][116642] Pillar render error: Rendering SLS 'default_user' failed. Please see master log for details.

Expected behavior
Applying the states in test mode should just work, as it's the case when grains are not defined in the minion config or if they are in the /etc/salt/grains file.

Summary for testing
-------------
Succeeded: 45
Failed:     0
-------------
Total states run:     45
Total run time:    1.109 s

Screenshots
None

Versions Report

salt-minion --versions-report
Salt Version:
          Salt: 3002.6
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.11.3
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.0
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: 3.9.7
        pygit2: Not Installed
        Python: 3.9.2 (default, Feb 28 2021, 17:03:44)
  python-gnupg: Not Installed
        PyYAML: 5.3.1
         PyZMQ: 20.0.0
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4
 
System Versions:
          dist: debian 11 bullseye
        locale: utf-8
       machine: x86_64
       release: 5.10.0-19-amd64
        system: Linux
       version: Debian GNU/Linux 11 bullseye

Reproduce the failure with the minion grains configuration, the default_user.sls pillar, and top.sls using the reported state.apply command. Start by tracing pillar rendering through salt/utils/templates.py and salt/pillar.py, comparing configured grains with grains from /etc/salt/grains. Done means the pillar renders and test-mode highstate succeeds when grains are defined in the minion configuration.