[two_dimensional_scrollables] Exclude trailing pinned spans from the non-pinned range

[m1roxx]

RenderTableViewport lays out and paints the table as nine regions: leading pinned, regular and
trailing pinned rows, each crossed with the same three column categories.
_updateFirstAndLastVisibleCell binary searches for the last regular row and column of the visible
range, and when no regular span reaches the trailing edge of the layout target it fell back to the
last index in the metrics map:

_lastNonPinnedColumn ??= _columnMetrics.length - 1;

Whenever trailingPinnedRowCount or trailingPinnedColumnCount is greater than zero, that last
index is a trailing pinned span. The regular range then overlaps the trailing pinned range, and
the same TableVicinity is visited by two regions in a single layout and paint pass.

_updateColumnMetrics and _updateRowMetrics already cap the same value correctly, with the rule
that _lastRegularColumnIndex and _lastRegularRowIndex express, so the two code paths disagreed.
This PR makes _updateFirstAndLastVisibleCell use those getters. The old fallback is kept for the
case where they are null — infinite spans with no null terminator — where trailing pinned spans
cannot exist, since _firstTrailingPinnedColumn and _firstTrailingPinnedRow both require a
non-null span count.

Fixes flutter/flutter#185842

Beyond the duplicated work

The overlap is not only wasted layout. Scrolling a table to the end with a trailing pinned span
throws, because two regions claim the same cell:

Expected to re-use an element at (row: 0, column: 19), but none was found.
  package:flutter/src/widgets/two_dimensional_viewport.dart:377  'elementToReuse != null'

and, once the spans carry a decoration, the non-pinned region reaches a cell whose paintOffset was
never set for it:

Null check operator used on a null value
  RenderTableViewport._paintCells.getColumnRect  (table.dart:1888)

Dragging through a 60x60 table with pinned and trailing pinned rows and columns throws
Expected to re-use an element at ... and TableViewCell for (row: 1, column: 58) could not be found before this change, and nothing after it. That is the same subsystem and trigger as
flutter/flutter#190800, but the specific assertion reported there did not
reproduce in my runs, so I am not claiming this fixes it.

Tests

Two regression tests are added to table_test.dart, one per axis. Each scrolls a table with a
trailing pinned span to the end, asserts that no exception is thrown, and asserts that the trailing
pinned span's decoration is painted exactly once — by the trailing pinned region only. Both fail
before this change.

Counting cellBuilder calls does not work as a test here: buildOrObtainChildFor caches children
for the frame and RenderObject.layout early-returns on unchanged constraints, so the duplicated
visit is invisible from the delegate. The new CountingSpanDecoration helper observes it through
the public TableSpanDecoration.paint API instead.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²