KPDB - CD and CT aggregations use water-included boundaries, so Brooklyn waterfront projects land in Manhattan

Found while adding a borough rollup for the CPP outputs (#2578).

KPDB allocates projects to community districts and census tracts with the water-included boundary files, dcp_cdboundaries_wi and dcp_ct2020_wi. Manhattan's polygons in those files run to the middle of the East River, so a Brooklyn waterfront project whose geometry reaches into the water intersects a Manhattan CD and takes roughly half its units by area share.

The coverage makes the mechanism plain: dcp_cdboundaries_wi is 468.2 sq mi and dcp_ct2020_wi is 468.3, against 302.1 for both dcp_nta2020 and dcp_cdta2020. NYC's land area is about 302 sq mi.

11 records are split across two boroughs in longform_cd_output, and the same 11 in longform_ct_output. Zero are split in longform_nta_output. Every one is a Brooklyn East River waterfront project that sits wholly inside a single Brooklyn NTA:

Only two carry net units, so the visible damage is small: on the 26Q2 nightly build 404 units of River Ring land in Manhattan CD 103 and 474 of 27-41 West Street in CD 106. That is 878 projected units credited to Manhattan that belong to Brooklyn. cpp_housing_growth_cd already ships this, and a borough rollup built on CD inherits it.

The fix is probably to swap to the land-only dcp_cdboundaries and dcp_ct2020, which developments and cpdb already use. Two things to check first:

• the post-hook fallback that assigns unmatched projects to any boundary they intersect. Against land-only boundaries a project sitting entirely over water matches nothing, so it either lands arbitrarily or gets no boundary at all.
• the 10% coverage rule for polygon_mode projects. A waterfront project's footprint is partly water, so its land share may fall under the threshold for a boundary it genuinely belongs to.

Everything downstream of the CD and CT aggregations moves when this changes, not just the CPP outputs. Worth noting the old PoC pipeline read future_units_by_ct, so its tract numbers carry the same problem.

Start by locating the KPDB CD and CT aggregation entry points and the post-hook fallback that assigns unmatched projects. Compare their use of dcp_cdboundaries_wi and dcp_ct2020_wi with the land-only boundary tables, then inspect polygon_mode handling and the 10% coverage rule. Validate the listed waterfront records in longform_cd_output and longform_ct_output, plus downstream cpp_housing_growth_cd results, without introducing arbitrary assignments for water-only projects.