Inconsistent quantity display: lossy fraction approximation (1 5/8 cup shown as 1 2/3 c) and no control over unit conversion

## Summary

A user report from the community: fractional quantities are displayed inconsistently between the web UI and the terminal, the terminal's fraction rendering is lossy (shows a *different number* than what was written), and quantities are silently converted to a different unit ("best unit") with no way to opt out.

> I created a test recipe with `@milk{1 5/8%cup}`. In the web UI, this ingredient is displayed as **1.625 c**, which is correct; however, for measuring purposes I would prefer it shown as **1 5/8 cups**. When displaying the same ingredient in the terminal with the `cook recipe` command, I get **1 2/3 c** which is the format I prefer (although cups would be better than just c); however, it is the wrong number. I tried `@cocoa{5/8%cup}` as another ingredient. This is displayed as **10 tbsp** in both the web UI and the terminal, which is not my preferred units. Are there settings to control when and how units are displayed or converted?

## Reproduction

`units-test.cook`:

```cooklang
@milk{1 5/8%cup}
@cocoa{5/8%cup}
```

```
$ cook recipe units-test.cook

Ingredients:
cocoa 10 tbsp
milk 1 2/3 c
```

Reproduced on current `main` (post-0.33.1).

## Problems

1. **Lossy fraction approximation in the terminal.** `1 5/8` (1.625) is rendered as `1 2/3` (~1.667) — a ~2.6% error presented with no indication it's approximate. The fraction display only considers halves, thirds, and quarters, so eighths (very common in US kitchen measures) get snapped to the nearest third. For measuring purposes this is actively misleading; `1 5/8` is exactly representable.
2. **Web UI and terminal disagree.** The web UI shows the raw decimal (`1.625 c`), the terminal shows an approximated fraction (`1 2/3 c`). Same recipe, two different numbers.
3. **Silent "best unit" conversion.** `5/8 cup` becomes `10 tbsp` in both UIs. The conversion is exact, but the user wrote cups and there is no setting to keep the unit as authored.
4. **No display/conversion settings.** There's currently no way to control fraction vs. decimal rendering, unit abbreviation (`c` vs `cups`), or whether unit conversion happens at all.

## Notes on where this comes from

- The terminal ingredient list goes through `group_ingredients(converter)` (`src/util/cooklang_to_human.rs`), which fits quantities to a "best unit" — that's the `5/8 cup → 10 tbsp` step — and then renders via the cooklang-rs quantity `Display`, which applies the lossy fraction approximation. The fraction/approximation behavior itself lives in cooklang-rs, so part of the fix may be upstream (allowing eighths/sixteenths for imperial volume units, or exposing the fraction config).
- The web UI renders the raw scaled value, hence the decimal.

## Possible directions

- At minimum, never show an *approximated* fraction as if it were exact (either show the exact fraction when one exists — `1 5/8` does — or fall back to decimal, or mark approximations with `~`).
- Align web UI and terminal rendering so the same recipe shows the same numbers.
- Add user-facing settings (CLI flags and/or config) for: keep-authored-units vs. best-unit conversion, fraction vs. decimal display, and full unit names vs. abbreviations.

Start with units-test.cook and the reproduced `cook recipe units-test.cook` output. Read `src/util/cooklang_to_human.rs`, especially `group_ingredients(converter)`, then trace the cooklang-rs quantity Display behavior and compare it with the web UI's raw-value rendering. Done should define consistent, non-lossy quantity display and clarify how authored-unit preservation and display settings are handled.

Written by the indexing model from the issue text.