Settings: Profile sampling presets (Thinking / Instruct / Coding / Custom)

[El-Patronum]

Adds a Profile control to the inference popover, directly above Sampling, matching the existing popover layout (InferenceSection + segmented picker + caption hint).

Split out of #273, which now carries only the unrelated markdown-table bug fix.

Profiles

Profile	Temperature	Reasoning
Thinking	1.00	on
Instruct	0.60	off
Coding	0.60	on
Custom	user's own	user's own

Temperature and reasoning are the only knobs that differ between the named profiles, so they are the only knobs a profile writes. Top P / Top K / Presence Penalty are deliberately left untouched rather than given invented per-profile values — whatever the model and the user already have stays put.

Selecting Custom is a deliberate no-op: "Custom" describes values the user already owns, so there is nothing for it to write.

Two design points worth reviewing

1. Nothing is ever disabled. Every slider and the reasoning picker stay draggable at all times, including while a named profile is selected. A profile is a shortcut, not a lock.

2. The selection is derived, not stored. There is no @State for the profile. activeProfile computes it from the live temperature / reasoningMode drafts:

private var activeProfile: SamplingProfile {
    SamplingProfile.named.first { profile in
        guard let t = profile.temperature, let r = profile.reasoningMode else { return false }
        return abs(temperature - t) < 0.001 && reasoningMode == r
    } ?? .custom
}

That is what makes "the moment the user moves a slider it becomes Custom" fall out for free — there is no stored selection to invalidate, and the picker can never claim a profile whose values are no longer on screen (e.g. after seedDraftsFromCurrentState() re-seeds from the daemon). The three named profiles have distinct (temperature, reasoning) pairs, so the derivation is unambiguous.

One consequence, called out deliberately: if the user hand-dials exactly onto a profile's pair, the picker shows that profile rather than Custom. That seemed strictly better than the alternative — the state genuinely is that configuration, and it avoids "nudge a slider up and back down, still says Custom".

Temperature is compared with a tolerance well under the slider's 0.05 step rather than with ==.

Incidental fix

runEnterChoreography(rowCount:) goes 8 → 9. The popover reveals sections one row at a time and each section gates on rowsVisibleCount > n; adding a section without bumping the count would leave the last one (KV quantization, now at > 8) permanently invisible.

Reasoning-unsupported models

applyProfile applies temperature, then early-returns before touching reasoning when reasoningSupported is false, so a profile can't fabricate a mode the model cannot honour.

Proof

• swift build: clean, no new warnings in the touched file.
• swift test: 572 passed, 1 failed — testDaemonSupervisorStartsFakeProcessAndKeepsLogsBounded, which passes in isolation (verified) and lives in MTPLXAppCore's daemon supervisor, a module this view-only diff does not touch.
• Derivation table verified against a standalone replica of the logic: all three profiles round-trip, all three are mutually distinguishable (Instruct and Coding share a temperature and separate on reasoning), and every one-step deviation on either knob falls to Custom.

[El-Patronum]

Closing: dropping the profile presets. The markdown-table bug fix this was split from stays open as #273.