Exercise 3: The Honest Limit, and When It Would Matter — Possible Solution
====================================================================

THE LIMIT NAMED IN THE WARN-BOX
------------------------------
Bumping version causes every component that consumes ItemsContext to
re-render, including ones whose own displayed data didn't actually
change as a result of that particular mutation. The Context has no way
to tell a component "you specifically don't need to update this time" -
every consumer re-renders on every single version bump, regardless of
whether the change was actually relevant to it.

A SCENARIO WHERE THIS WOULD ACTUALLY MATTER
------------------------------
At this app's own realistic scale - a handful of features, and
mutations that happen when a user manually adds or uses an item, at
most a few times a minute - the extra re-renders are computationally
trivial and genuinely invisible. This would start to matter in an app
with many more Context consumers (dozens of components reading from
the same shared context, not three or four) combined with much more
frequent updates - for example, a real-time collaborative app where
many users are mutating shared data continuously, causing constant
re-renders across a large tree of components that mostly didn't need
to update. In that situation, a more granular state library (Zustand,
Jotai) or splitting into several smaller, more targeted contexts would
avoid re-rendering components that have no real reason to.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly restates the specific mechanism behind the limit (every
consumer re-renders regardless of relevance) rather than a vague "it's
not efficient," and it describes a genuinely different scale (many more
consumers, much higher update frequency) rather than simply saying "a
bigger app" without specifying what dimension of "bigger" actually
matters here.