Bind physical factory areas to planning blocks

[ApocDev]

Goal

Associate a PyOps planning block with one or more physical areas in the connected Factorio save so built-machine coverage and scaling status can be calculated per block instead of force-wide.

Proposed workflow

• Let the player choose a PyOps block and select an area in-game, or pin the player position as an anchor.
• Support multiple areas per block for distributed builds and outposts.
• Store surface plus bounding area/anchor with the project block.
• Count machines and running recipes inside the bound areas for block-scoped build status.
• Preserve force-wide recipe coverage as the fallback when a block has no binding.

Assisted discovery

PyOps may suggest an area by finding machines running a recipe unique to the block, spatially clustering nearby related machines, and asking the player to confirm or adjust the result. Heuristic matches must show confidence and must not silently claim ownership because blocks can overlap or share recipes.

Build-state semantics

• Unbuilt: none of the block recipes are running in its bound areas.
• Partially built: some, but not all, required recipes are running.
• Built, not scaled: every required recipe has at least one running machine.
• Scaled: scoped counts meet the planned machine totals.

Recipe coverage should accept an older compatible machine running the recipe even when the plan selects a newer tier. Machines that cannot report recipes need a machine-presence fallback.

Related

Related to #3, which navigates from a selected in-game machine using recipe association and already identifies physical block tagging as the more precise future mapping.