Rename prior derived type to prior_spec to fix Fortran interface name collision

[AdamOrmondroyd]

The problem

The Fortran interface didn't compile. Building the stock driver fails:

src/drivers/polychord_fortran.f90:41:38:

   41 |     call run_polychord(loglikelihood, prior, settings)
      |                                      1
Error: Derived type 'prior' is used as an actual argument at (1)

priors_module defined a derived type called prior (the parsed ini-file prior
specification), and interfaces_module imports it at module level for the
priors module variable.

gfortran drags that type name into any scope that does use interfaces_module
— even with an only: clause naming just run_polychord, and even if the
import is renamed inside interfaces_module. The type lands in the user's
namespace as a hidden derived-type symbol called prior.

Using it as a function still works (theta = prior(cube) compiles), but passing
prior as an actual argument makes gfortran resolve the name to the type and
reject it. Which is exactly what we ask users to do: likelihoods/fortran/likelihood.f90
tells you to write a function called prior, and the driver passes it straight
to run_polychord. Renaming it at the use site (my_prior => prior) doesn't
help either — the leaked symbol still wins.

The fix

Renamed the derived type prior → prior_spec, and updated its five users.

prior_spec because the type isn't a prior — it describes one: which parameters
it covers (hypercube_indices / physical_indices), which kind it is
(prior_type), and that kind's numbers (parameters). It's what
hypercube_to_physical consumes.

Names considered and rejected:

• prior_type — matches param_type in params_module, but _type already
  means "enum tag" throughout priors.f90 (uniform_type, gaussian_type, …),
  the type's own field is prior_type, and prior_type_from_string returns one
  of those integers, not the type.
• priors — collides with the variable of that name at every single use site,
  which is the same shadowing bug, self-inflicted.

Verification

• make polychord_fortran now compiles and links; previously it did not build at all.
• make examples polychord_CC polychord_CC_ini all build clean.
• ./bin/gaussian ini/gaussian.ini runs to completion, log(Z) = -0.087 +/- 0.188
  for the 20-D unit Gaussian.

Notes

• Source-compatibility break for any external code doing
  use priors_module, only: prior. It's an internal type for ini-file prior
  specs, so this should affect nobody, but flagging it. Happy to add a
  deprecated alias in priors_module if wanted — the alias itself is harmless,
  it was only the interfaces_module re-export that leaked.
• Pre-existing, untouched: write_paramnames_file (read_write.F90:965) and
  write_properties_file (read_write.F90:997) both import prior_spec but
  declare nothing of that type. Dead before this change too; left alone to keep
  the diff focused, happy to drop them.
• Added a make job to CI. It only exercised the python bindings before, which
  is why a completely unbuildable fortran interface went unnoticed. The new job
  builds the libraries, all three drivers and the examples, and smoke-tests one.
  Verified against master: every step passes there except Build fortran driver, which fails with the error above — so the job catches this specific
  regression and nothing else.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtxjPgndTpcYEnnATa1oHr