Phoenix contexts acknowledge that there are designs beyond CRUD. In CRUD applications the shape of the data in the page on the front end tends to dictate the shape of the data that is stored in the database. This is the hallmark of implementation coupling. Typically when you change something on one end that change ripples through to the other end (and any layers in between).

but the overlapping of three data layers - GraphQL, Ecto and Database schemas - concerns me in some way

That overlap may simply be a result of the technology being applied to an application with an “unsophisticated” domain - which wouldn’t be surprising if the entire point of the application is to clearly showcase how the technologies interact - without being obscured by complex application design concerns.

• The shape of the data in the RDBMS is largely concerned with efficient and effective storage and retrieval of data the application typically uses - clearly the inserts, updates and queries influence the shape - but there may be optimization concerns to favour the performance characteristics of certain insert, update and query operations. That means that the capabilities of the RDBMS engine are going influence the shape of the data inside the database beyond the bare needs of the application.
• Ecto brokers between the shape of the data needed by the application vs the shape of the data stored in the database. The shape of the data for the application is what you are primarily concerned with because that shape is influenced by the processing capabilities of the application.
• GraphQL should be primarily concerned with the shape of the data that is needed by the client of the application (in the spirit of Consumer Driven Contracts). The application should typically hide certain implementation details from the client to stop the client becoming coupled to the implementation details of the application. Also the application could derive (aggregate) some information that doesn’t explicitly exist in the database for the purpose of exposing it to the client via GraphQL.

What I think would be best for graphql projects is just have the database, have a graphql layer, and have both the API and Web Controllers access the GraphQL layer (so Controllers just call into the local GraphQL bit), that way it all goes through a single defined point that handles auth and all.

Maybe you can find a discussion on some of the problems you found here? Five Common Problems in GraphQL Apps (And How to Fix Them)