Queue the design work on a view

Designs the exterior on this view and shows it on the photo: materials applicable in the building's country, products actually sold there, and the build-up behind the surface. Returns the render immediately with a non-terminal status: its id is the job id. The finished file_url is a permanent public link (no signature, no expiry) that can be handed to a person as it stands, and that keeps working for anyone it reaches.

Colour and brand are two different fields. colors carries the palette: palette:1, #RRGGBB, and the order carries the 60/30/10 role, the first entry being the dominant wall colour. brand_selections carries real manufacturer products at whatever precision is known — siding:brand:12, siding:line:40@double-4-dutchlap, siding:product:88@double-4-dutchlap, paint:brand:3, paint:product:412 — where the optional @profile suffix pins the siding geometry. Ten entries each.

seed is optional; omit it unless reproducing an earlier render, the server generates and returns one.

render_effort asks for a tier: BRAINSTORM is the quickest, STANDARD the middle, HIGH the slowest and most detailed. Some buildings resolve the tier on their own and the request never reaches the render, so the response echoes what was asked for rather than what ran.

Refining an existing design. With mode: refine the render iterates on parent_render_id instead of the view photo: the instruction in prompts.prompt_concept is applied to that finished picture and everything it does not mention is kept. The parent must be completed, must belong to the same building, and must sit in the same view stack as the render being created (a main render refines a main render; a secondary view refines within its own stack) — otherwise this answers 422.

Refining a main view does not overwrite the picture: the server forks a new design, so the design the result lands in is the one reported by relationships.concept_angle.meta.concept_id of the response, not the one in the path.