Your question has a lot of layers to it which make a simple answer elusive. At first blush the answer seems obvious - of course all stakeholders should have visibility into the requirements. But what does that actually mean?
To answer this please let me summarize your question to make sure I understand the situation correctly. According to your description the process for gathering requirements from your customers is informal - requirements come in via various means including e-mails and action items that are the result of meetings with customers, and that you are not included in these email or meeting discussions. It also sounds like your customers may have various level of experience in writing requirements for software. You have a person in a program-management role who is attempting to mediate these requirements to you, and whose processes for managing those requirements are minimal at best. To complicate matters further, it sounds like you do not trust the mediation and translation of the requirements by your PGM. Information that you believe is essential to fulfilling requirements is missing (Why and What). I also suspect that you may feel like the PGM is over-specifying the HOW in the requirements which would impinge on the design authority of you and your team - after all - As Engineers the HOW should be largely left up to you, especially since you are the people who are going to be held accountable for failure. The net-result of all of this is that you want to be able to see the whole "chain of custody" or history of a requirement in order to defend yourself and your team against certainty of being held accountable for failure due to what was ultimately a badly conceived/written/managed requirement. Is this correct?
My first reaction after reading your question was to think - this is a situation where agile practices could really make a difference on your team.
For instance, one of the root problems seems to be a lack of trust between you and the GPM. In agile we try to value "Individuals and interactions" over "Processes and tools". Doing this is very hard when trust has broken down between team members - and it is very tempting to try to find a solution by modifying the processes which have led to loss of trust. The first step in reestablishing the trust is always open and honest communication. Have you discussed this problem with the GPM in terms the GPM can understand and accept? It's not an easy thing to explain to someone that the reason you want a process change is because you don't trust them or their judgement. But that is exactly what needs to be communicated. You may also be surprised by the underlying reasons that the GPM wants to over-specify the HOWS and not communicate the WHY and WHAT. Perhaps this conversation can lead to a mutually beneficial compromise? One avenue I would suggest is agreeing on a format/template for the requirements produced by the GPM - my personal favorite way to specify requirements is via user-stories... but what you call them, their format or even the level of detail is not as important as the agreement about what they must communicate. Also remember than unless your PGM is a complete sociopath that they are going to be motivated by many of the same things you are. No one wants to be part of a losing team, everyone wants to succeed at least at some level. Upfront recognition of this will make this discussion a lot easier for everyone.
My second reaction also involves one of the agile principals - Customer collaboration over contract negotiation. It sounds to me like this PGM has inserted themselves between you and the customer - which I believe is an error on both of your parts. The PGM should have nothing to fear by allowing you to interact with the customer directly - better communication with the customer will ALWAYS result in a better product. This is common sense. It may be that the PGM's instinct here is actually to actually protect you from randomization by the customer. This is a noble instinct - but it can sometimes be a problem if the PGM does not recognize a difference between structured interactions (such as during a product demo or a product-backlog grooming session) and randomization. Perhaps the PGM doesn't see a difference between seeking out the customer's opinion about the best way to execute a feature and allowing the customer to lobby you for new features or task priority directly? The answer here is the same as before - open and honest communication and an understanding and agreement between you the PGM of what aspects of communication with the customer each is responsible for. At the very least, I would ask to be included in any discussions about new requirements. This is a very reasonable request and should not be threatening to your PGM if they think about it. But it's success will also depend on you as much as the PGM. Remember that the engineers role in discussions with customer's is primarily one of listening - which also means asking a lot of questions. Try not to engage with the customers directly about the priority or value of a feature request in these meetings - that is the job of the PGM who should then advocate the customer's position in their negotiations with you about priorities and scheduling.
Another agile principal that can help here as that of "Deliver[ing] working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". If you can get your PGM to schedule software delivery in small incremental units that would be best, especially if you can get a commitment that no changes to requirements will be accepted after that incremental unit of work has started (i.e. no changes to a sprint after it has started, using SCRUM phrasing). Again, open and honest communication is key here. You need to communicate clearly what you are committing to delivering in order for the PGM to reasonably trust that you will achieve that commitment. Then you need to prove that you met that commitment by demonstration or openly and constructively confront failure when it occurs.
Finally - and least - consider advocating for adoption one of the cannon of formal agile practice systems such as SCRUM. To be clear - I think that adoption of an agile strategy will solve most of your problems without any need to change any of your management tools at all if that is what you are your Peers are comfortable with. But I also think that the social and cooperative underpinnings of methodologies like SCRUM could also help out A LOT.
For instance - the roles and processes around requirements gathering and management are very well defined in SCRUM with a tremendous amount of support in both the Programmer community and in the PM community. Likewise issues around communication with the customer. This could be a strategic move as well if it turns out that your PGM is simply an irrational control-freak who hates customers and programmers and can't wait to leave every night so they can go torture kittens or something... Advocating a well understood and industry accepted solution will make it easier for you to bypass that person if that ultimately ends up being what is required. For more information about SCRUM, please see https://www.scrum.org/. Also, keep in mind that SCRUM is an agile process. What this means in practical terms is that you should not feel constrained by someone else's opinion of what SCRUM is - if it works for you and your team then that is good enough so feel free to experiment!