fix(android): ContentLayout measures children against unreduced parent spec - #11439

…t spec

ContentLayout.onMeasure passed its own widthMeasureSpec/heightMeasureSpec
straight to measureChild without deducting its own padding first, while
onLayout does respect that padding. When ContentLayout carries padding
(e.g. edge-to-edge system bar insets applied as padding on an ancestor),
children measure against the full parent size but are laid out into the
smaller padding box, and an ancestor with clipChildren=true silently
clips the difference. StackLayout/DockLayout already reduce the spec by
their own padding before measuring children; ContentLayout now does the
same.

Also fixes a latent onLayout typo where childBottom subtracted
paddingRight instead of paddingTop, harmless only when horizontal and
vertical padding happen to match.

The previous commit's onLayout change used (paddingTop + paddingBottom)
for childBottom, reasoning by analogy with the childTop/childBottom
naming. That's wrong: CommonLayoutParams.layoutChild's FILL_VERTICAL
branch passes the given top/bottom straight through to the child's
final bounds when there are no margins, so childTop already accounts
for paddingTop on its own and childBottom must not subtract it again.

Verified on-device: constructing a real ContentLayout with padding
(0/156/0/72) and a MATCH_PARENT child and comparing measured vs
laid-out height caught this immediately (measured 2628, laid out
2472) before it reached real usage. The correct computation only
drops paddingBottom, matching how childTop only adds paddingTop:

    childBottom = bottom - top - paddingBottom;

Re-verified the same way: measured and laid-out heights now both
report 2628, matching the padded content box exactly.