[BUG] strange grains targeting behavior after minion reboot

Description
After a minion reboots, at least some of its grains are incompletely available for targeting until running saltutil.refresh_grains against it. This is a new behavior, but I'm not sure when it appeared -- possibly with 3002.

Setup
Set up, for example, a master and minions that use the tier grain.

Steps to Reproduce the behavior

$ salt -C 'wr* and G@tier:stage' test.ping
wr-stage-003:
    True
wr-stage-002:
    True
wr-stage-005:
    True
$ salt -C 'wr-stage-002' system.reboot
wr-stage-002:

Wait a minute for the minion to reboot, and confirm:

$ salt -C 'wr-stage-002' test.ping
wr-stage-002:
    True

Here's the strange part -- this works, as expected:

$ salt -C 'wr* and G@tier:stage' test.ping
wr-stage-003:
    True
wr-stage-005:
    True
wr-stage-002:
    True

but this doesn't:

$ salt -C 'wr*2 and G@tier:stage' test.ping
No minions matched the target. No command was sent, no jid was assigned.
ERROR: No return received

even though the same command gets a correct result without the grain targeting:

$ salt -C 'wr*2' test.ping
wr-stage-002:
    True
wr-prod-012:
    True

After running

$ salt -C 'wr-stage-002' saltutil.refresh_grains
wr-stage-002:
    True

this works as expected:

$ salt -C 'wr*2 and G@tier:stage' test.ping
wr-stage-002:
    True

Expected behavior
After rebooting a minion, it should be targetable using grains.

Versions Report

Salt Version:
          Salt: 3002.2

Dependency Versions:
          cffi: Not Installed
      cherrypy: unknown
      dateutil: 2.7.3
     docker-py: Not Installed
         gitdb: 2.0.5
     gitpython: 2.1.11
        Jinja2: 2.10
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: 2.6.1
  pycryptodome: 3.6.1
        pygit2: Not Installed
        Python: 3.7.3 (default, Jul 25 2020, 13:03:44)
  python-gnupg: Not Installed
        PyYAML: 3.13
         PyZMQ: 17.1.2
         smmap: 2.0.5
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.1

System Versions:
          dist: debian 10 buster
        locale: UTF-8
       machine: x86_64
       release: 4.19.0-13-amd64
        system: Linux
       version: Debian GNU/Linux 10 buster

Start by reproducing the post-reboot targeting commands with the tier grain, then compare behavior before and after saltutil.refresh_grains. Trace the minion grain refresh and compound-targeting entry points involved in those commands. Done means a rebooted minion is immediately selectable with wr*2 and G@tier:stage without manually refreshing grains.