I don't see many problems here.
Authorship is often a term used in copyright law to refer to protections provided to the creator of a work. It doesn't really apply to what you do at work, since in most cases the company owns the work. You don't have any say in how the product is sold or licensed. The Law Stack Exchange may be a good place to explore your legal relationship to your employer and copyright law.
Squashing commits in git is a common practice to keep the history of a shared code branch clean and easy to follow. A single developer may make many commits when developing a feature, but only a single commit into an integration branch is required to make it easier to cherry-pick the changes into other branches or revert the changes. There are plenty of good reasons to squash commits, and the act of squashing is not unethical by itself.
It would be unprofessional and unethical for someone to attempt to hide, distort, or misrepresent the work of their colleagues. However, code commits are also not a good way to measure contributions. There are plenty of ways to contribute as a software developer that aren't code commits - design, pair programming, code reviews, manual testing are just a few examples of work that doesn't get associated with git commits.
It seems like the perceived problem is that employees aren't recognized for their work because their name doesn't appear in the commit history of a code repository. If the organization is actually using that as a metric for employee performance, that would be a broader organizational issue. What I don't see is any evidence that this is happening, though.
If you believe that your contributions to the team, the project, and the product are not being seen, that's a conversation to have with your manager. However, just because your name isn't associated with specific code changes doesn't mean that the team doesn't see your contributions.
If you are in an organization that values code commits and having your name in the source code repository history, I'd consider that a poor working environment, especially given the technical practices. There's a big disconnect between the team choosing to use a perfectly fine technical practice and how the organization measures team success. It could range from malicious intent, abusing the technical practices to earn better performance reviews, to not understanding the implications of the technical practices on others. The underlying problem, however, is how the organization measures performance.