Appreciate this detailed follow-up
Can you advise what the cause was and how you fixed it and confirmed it fixed? It will help others searching in the future.
>>during maintenance today of the gateway, there was a security feature that was enabled during the upgrade. Regarding the timestamps when Pihole stopped reporting logs, lined up about the approx. time the firmware pushed. I went looking into the gateway security settings and disabled the setting
Regarding the earlier command... your Unbound install was good. Following the online guide it ends up on port 5335, which yours is. So then it's just a case of making Pi-hole use it as its only upstream server.
>>OK that helps me understand and makes sense
Your trying out that dig command that jfb posted showed that Pi-hole wasn't able to reach its configured upstream server, but that querying Unbound directly on port 5335 worked fine.
>>OK so @x.x.x.x vs @x.x.x.x -p 5335
understood
....Note, that this bug was found and fixed today in Core v6.0.4 .
>>That's awesome the team found and patched that so quick!
One of the bandaid fixes for that bug was to run that command I gave but with servers for Quad9, a common external provider.
>> hm ok, that's good to carry with me for any future troubleshooting
I see you did mention it was a fresh install, I didn't notice that at the time. So if you had a previous upstream configured that was now missing or broken – such as cloudflared on port 5035 – or if you had encountered this bug... either way, what you really needed in there was your working Unbound server on port 5335.
>> I did perform a fresh install of Pihole today as tutorials and guides recommended and advising performing a 'dirty' or 'inline' upgrade was not advised coming from version 10 (to backup and make a fresh SD) When going through the initial install wizard I selected 'Cloudflare (DNSSEC)' as the DNS provider out of the gate. I then remembered from my v5 build that unbound was probably not deployed on v6 today and went down a rabbit hole attempting to deploy and test it, which led me here on 'best practices' to verify my current knowledgebase on the topic
So I took that bandaid command and adjusted it to configure Pi-hole with your Unbound server. After running it, your first dig command now worked, because Pi-hole now had a valid upstream server, your newly installed Unbound.
>> Thank you so much for hashing it out together, you had excellent feedback and were very patient during the discussion. Sometimes I fall out of the loop as my previous deployment was solid for many years and wanted to be sure I completed the current v6 deployment in the same manner
why did you install Bullseye and not the latest Bookworm? If that was an oversight
>> I actually just checked that now as I may have gotten the codenames confused previously and have confirmed the current OS is bookworm
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
Going back to the original post regarding 150max query errors that occurred on v5, and I saw again working with you on v6. I did deploy this again today, as respect to what the mod stated in that post, I have had a hard time finding the proper fix to address this concern... I will have to keep digging on that.
If you have any suggestions on this I am all ears 
Thank you again for your time on this, it connected the dots, and I hope this thread can assist others. We all come from various skillsets and help one another in these communities, it is really great to see everyone that helps one another.
Very appreciative!