refactor(hm-plugin-cloud): render_prefs returns a (bool, bool) tuple whose two fields are trivially swappable

[markovejnovic]

The smell

render_prefs() returned (bool, bool) — two values of the same primitive type with no type-level distinction. Call sites destructured positionally:

• crates/hm-plugin-cloud/src/verbs/build.rs:59 — let (color, logs) = …
• crates/hm-plugin-cloud/src/verbs/job.rs:72 — let (color, _logs) = …

Swapping the two values in the function body, or a future call site binding them in the wrong order, compiles silently and inverts color/log behavior.

The change

render_prefs() now returns a named struct so each field is named at construction and at every call site:

#[derive(Debug, Clone, Copy)]
pub struct RenderPrefs {
    pub color: bool,
    pub logs: bool,
}

Call sites bind prefs and read prefs.color / prefs.logs instead of relying on tuple position. Behavior is unchanged — the same two values flow to hm_render::renderer_for in the same order.

(#[derive(Debug, ...)] is required because the crate denies missing-debug-implementations.)

Type-safety pattern

This applies the ripgrep/fd "replace bool/bool pairs with named fields or enums" guidance: same-typed positional booleans are a classic source of silent swap bugs. A named struct names each flag at construction and at every use site, so a wrong-order binding no longer type-checks into an inverted-behavior bug. This is a focused, behavior-preserving change touching only this function and its two callers.

Validation

Only cargo check -p hm-plugin-cloud was run locally (passes). Full CI runs on this PR.