Masonry module: test coverage gap before integration - prioritization input needed

[parthdagia05]

While exploring the masonry module to integrate in the main, I noticed something

Current state: Only 3 of 8 masonry submodules have any tests at all :-

• TowerModel (13 public methods including connectBricks, mergeIn, detachSubtree) -- 0 tests
• WorkspaceManager (6 methods including cross-tower connection) -- 0 tests
• palette/, state/, tower/utils -- 0 tests
• The --passWithNoTests flag in the test script means CI passes silently even with no coverage

The 3 files that do have tests (collision-detection, brick path, reverse-mapping) follow clean patterns -- co-located spec/ dirs, data-driven cases, Vitest globals. So the conventions are already established.

Since we're planning to integrate masonry into the main app and build snapping and execution on top of it, I think we need a test foundation under TowerModel and WorkspaceManager first -- these are pure TS classes with no React dependencies, so they're straightforward to unit test.

I'd like to start working on this. Before I do, wanted to check with @meganindya @justin212407 @sa-fw-an

1. Does this priority order make sense: TowerModel → WorkspaceManager → tower utils → palette utils?
2. Are there any planned refactors to these models that I should be aware of before writing tests against the current API?

[Rishi2600]

The priority order makes complete sense, @parthdagia05. Perhaps it's good to check with @meganindya, @justin212407, and @sa-fw-an in case there's anything needed on the overall structure!
Also, I am auditing a detailed documentation covering this testing area, especially so we can have a broader understanding of the structure. I will post it right after I am done auditing.
Thanks!

[parthdagia05]

@Rishi2600 you can share the documentation here too, so that we can make plan accordingly. The above idea which i shared was in short but a documentation would on it help a lot