Apply Textarea rows and cols defaults only when meta omits them - #209

Closes #212.

<textarea> now renders the rows and cols the caller asked for.

Cause

Textarea::__construct applied its defaults before parent::__construct had read $meta. __fieldmeta was still empty, so the is_null guard never fired and the default was always written first. __initializeMeta then routed the caller's value through setFieldMeta, which appends with a space when $blnOverwrite is false.

rows and cols each take a single valid non-negative integer. Browsers parse the leading digits and ignore the rest, so rows="5 4" reads as 5 — the caller's value was discarded with no error anywhere.

Fix

Move parent::__construct to the top of the constructor, so the guard reads the meta the caller actually passed. Same ordering Button::__construct already uses.

Tests

953 tests, 1754 assertions, green.

• customRowsAndColsFromMetaAppendToDefaultsDueToSetMetaBehaviour asserted the broken output as a KNOWN LIMITATION. Renamed to customRowsAndColsFromMetaOverrideDefaults, assertions flipped.
• Added unprefixedRowsAndColsFromMetaOverrideDefaults. The old test only covered fieldrows/fieldcols; the unprefixed form the class docblock documents had no coverage.
• toHtmlRendersDefaultRowsAndCols untouched and still passing.

For reviewers

Attribute order on <textarea> shifts — class now precedes rows/cols, because Element::__construct writes the class into __fieldmeta before the defaults land. Values identical, and the suite is order-insensitive (DOMXPath getAttribute). Anything string-matching on textarea markup would notice.

Unprefixed cols/rows also leak onto the wrapper <div>. Separate bug in Base::__initializeMeta, not touched here.