in #1235 cmdstan_model() queries the executable twice when it is already up to date

[jgabry]

Note: this issue is conditional on #1235 being merged eventually and documents an issue that will result from #1235 but won't be fixed in #1235 itself.

This issue was also prepared with the help of Claude Code.

cmdstan_model() on a model whose executable is already current runs
<exe> info twice instead of once.

model_compile_info() is called from two places: the up-to-date branch of
$compile(), which uses it to describe an executable the object did not build
and to detect when the requested cpp_options disagree with the binary; and the
end of initialize(), which merges the binary's metadata into $cpp_options().
When cmdstan_model() is called on a current executable, initialize() calls
$compile(), which takes the first path, and then runs the second itself. Each
call launches the model binary as a subprocess.

This is not a correctness problem — both calls return the same thing and the
merged result is identical. It is wasted work on a common path.

Measured on macOS:

• one <exe> info call: ~33 ms
• cmdstan_model() on an up-to-date model: ~83 ms

So roughly 40% of that call is the duplicate. Process creation is more expensive
on Windows and crosses the VM boundary on WSL, so the cost there is likely
higher but has not been measured. It is per model construction, so it is
invisible interactively and adds up in scripts and test suites that build many
models.

Neither call can simply be removed:

• initialize()'s call also runs after a real compilation (where $compile()
  never queries the binary) and for cmdstan_model(exe_file = ..., compile = FALSE) (where $compile() never runs), so removing it loses the binary's
  flags in both cases.
• $compile()'s call is what gives $cpp_options() a description of an adopted
  executable, and a direct mod$compile() on a compile = FALSE model never
  reaches initialize() again.

Noted rather than fixed in #1235, which was about removing state that could
drift out of sync with the executable. This is also likely to be reworked by the
outstanding "recompile when cpp_options disagree with the binary" work (the
skip("To be fixed in a later version") tests in
tests/testthat/test-model-recompile-logic.R), which need
info in the same place.