Fluid-fuel pool at factory scale: explicit supply-side designation, matched MJ flows

[ApocDev]

Follow-up to #25, which shipped the block-local pyops-fluid-fuel pool. Today the pseudo-fluid is in factory-solve's FREE_GOODS set (src/server/factory-solve.server.ts:30), so a block's generic "Fluid fuel (MJ)" import is invisible at factory scale — nothing verifies that any block supplies burnable fluid for it, and the fungibility the pool provides inside a block does no work between blocks.

Decided design:

• Demand side stays automatic: an unfiltered fluid-burner block imports generic MJ with no ceremony (as shipped).
• Supply side is explicit: a block becomes a fuel supplier only by adding a burn-fluid-* conversion and routing fluid into it, so its pyops-fluid-fuel output exports. A fluid exported without the conversion (kerosene as chemical feedstock) is never counted as fuel supply — no accidental conscription of fuel-valued exports.
• Factory level: remove pyops-fluid-fuel from FREE_GOODS and match generic MJ imports against designated MJ exports like any other good. pyops-electricity (grid utility) and pyops-heat (block-local by game rule) stay free.
• Align the assistant: submitBlock currently drops pyops-fluid-fuel from import lists like the other pseudo-goods; once MJ is a matched flow it should surface as explicit demand instead (noted as an open question when Generic fluid-fuel energy commodity (energy:fluid) for fungible fuel demand #25 landed).

The physical reading stays honest: the designated supplier's pipes carry a known fluid; consumers just don't have to care which. One "fuel farm" block can satisfy many generic consumers, and changing the factory's fuel of choice touches one block.

Fits the #91 model with no special cases (the conversion recipe is the supply-side producer gesture; routing surplus into it is a share pin), but doesn't depend on #91 — the FREE_GOODS change and the supplier flow work against the current solver.