Some things to think about based on what I've observed from your question:
While defining stories we had two stories one larger one that would allow some infrastructure to be made and a smaller ticket that had more apparent value that depended on it. Together they were bigger than we were happy with a story being.
This stuck out to me because it indicates a need to further refine the work at hand. The development team is ultimately responsible for managing and organizing their work, thus they should be empowered to refine the work until they are comfortable with the size, effort, and plan of attack from a development approach.
In sprint planning, the business was looking to add some small stories to a sprint, saw the small one and added it. It made sense to them to add a small valuable ticket.
This is another case where this issue can be mitigated by allowing the team to manage and organize their own work. The business can obviously be a stakeholder whose priorities can and should be taken into account in the product backlog, but the sprint backlog is owned 100% by the development team. The development team members decide what gets pulled in based on the priority and shared objectives via work in the product backlog.
By making your work transparent (using a Kanban board via JIRA indicates you're already in a good place with this), you can link dependencies and work through those dependencies with your team by empowering them to reorganize their work in a way that can provide value in the form of an increment. JIRA supports flags. You can also link cards by
- Opening the card you want to link
- Clicking 'More' (...) > Link > Jira Issue
- Choosing the type of Issue
- Specifying the other card you want to link this card to (text search works here)
- Adding a comment if needed
That said, it makes sense to address the process breakdown instead of masking the issue with tooling. There are many models for properly breaking down work into manageable pieces. I concur with the INVEST model but more can be found with a simple Google search in the event one fits your needs better than another. Tooling customization can make the team issues more transparent, which should mitigate a need for automated warnings, but coaching the team and larger organization on Agile principles addresses the larger issue you've identified in your question. Good luck; hope this helps!