Add polygon startbox column type

[burnhamrobertp]

Add polygon startbox editing support

Adds a new "Map Startbox (Polygon)" column type alongside the existing rectangle-only one. The idea is that the maps table can be switched over to the polygon type when needed, without breaking any existing data.

Is part of what would need to be done - at some point - to support beyond-all-reason/maps-metadata#605

What changed

• New MapStartboxPolygon field type registered in the BAR Custom group
• The underlying MapStartbox component now handles N-vertex polygons (drag vertices, click edge midpoints to insert, delete vertex mode)
• Drag-to-move: click and drag inside a startbox to reposition the whole shape
• Wider editor layout for the polygon type since there's more going on
• Backward compatible: legacy 2-point rectangles are expanded to 4-vertex polys for editing, and compressed back to 2-point on save if they're still axis-aligned

Related PRs

• Core Game - Polygon startboxes via mapmetadata modoptions beyond-all-reason/Beyond-All-Reason#7513
• Chobby Lobby - Polygon startbox infrastructure (rendering, encoder, modoption injection) beyond-all-reason/BYAR-Chobby#1184
• New Lobby - Allow polygon start boxes beyond-all-reason/bar-lobby#574
• New Lobby (active follow-up, amends Develop buildship-ai/rowy#574): Send polygon startboxes to the game beyond-all-reason/bar-lobby#601
• Maps-Metadata - Allow polygon and spline startboxes alongside legacy rectangles beyond-all-reason/maps-metadata#615

What I didn't test

I didn't do a full end-to-end test within Rowy itself — getting Firebase Auth working locally was more hassle than it was worth for this. I built a standalone HTML test harness to validate all the editing interactions (vertex drag, insert, delete, move, text input, save/load roundtrip, backward compat). Since this is a new column type that doesn't touch the existing one, it should be safe to try out on the live instance without risk to current data.

AI disclosure

GitHub Copilot was used to assist with implementing this change, particularly since I couldn't run rowy locally.

[p2004a]

It doesn't even build so can't test it:

> yarn build
yarn run v1.22.19
warning ../../../package.json: No license field
$ craco build
Creating an optimized production build...
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
Failed to compile.

Module not found: Error: You attempted to import /src/components/fields/MapStartbox/DisplayCell which falls outside of the project src/ directory. Relative imports outside of src/ are not supported.
You can either move it inside src/, or add a symlink to it from project's node_modules/.


error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

After I fix that, more stuff pops up, it's unusable.

[burnhamrobertp]

Hrm that's really odd. This shouldn't been ready for integration. Maybe I left off changes accidentally or have things that aren't pushed? I'll figure it out

[p2004a]

Adds a new "Map Startbox (Polygon)" column type alongside the existing rectangle-only one. The idea is that the maps table can be switched over to the polygon type when needed, without breaking any existing data.

This seems unnecessary and possibly incorrect statement: you already in this PR change the implementation of the component, so unless I'm missing something, the existing map startbox field will just get ability of doing polygons. The "field type" is only cosmetic, it doesn't change the fact that underlying component can do polygons.

[burnhamrobertp]

Removed the new column type since - as you pointed out - not duplicating the MapStartbox component meant my changes would be present even on the old column type, and since the data structure is the same by design, there's no reason (or significant risk) in just changing the existing column in-place.

[burnhamrobertp]

Also, in running through this...the UX leaves something to be desired (particularly for those who specifically want square startboxes, for whatever reason). I can either add it to this PR or i can intentionally keep it as a separate feature. If you're wanting to run through and test it yourself anyways (given the desire to spin it up when it errored on you) it seems like including it in this PR would be fine?

[p2004a]

I don't have opinion yet because I wasn't able to test anything.

[burnhamrobertp]

I went ahead and included the improved UX. Its purely front-end code anyways and shouldn't change the reviewability of the PR itself.