Story: Hotfix: a Boost library landed without its vcpkg port

Every continuous Linux job is red, in all four configurations, at one translation unit:

projects/ores.utility/include/ores.utility/decimal/decimal.hpp:24:10: fatal error:
  'boost/multiprecision/cpp_dec_float.hpp' file not found

The decimal amount type, which Decide how an exact decimal is represented in C++ settled and commit 466ea3109f then added, gives the estate exact base-ten arithmetic with boost::multiprecision::cpp_dec_float_50, and vcpkg.json was not told. vcpkg installs Boost as one port per library, so boost/multiprecision is not there unless it is declared or arrives as another port's dependency. It compiled for whoever wrote it, whose vcpkg tree predates the include or was installed by hand, and fails on every clean install – which is every continuous build, on every platform, not only Linux.

The fix declares the port. The check that would have caught it at pull request time did not exist, so this story adds one as well: every boost/<library>/ the tree includes must have a port behind it, or the closure of a declared port, so a library that arrives transitively is not declared twice.

• vcpkg.json declares boost-multiprecision, and a clean configure installs it.
• The decimal translation unit compiles, and the decimal and bond leg amount suites pass.
• check_boost_dependencies.py passes on the tree and fails when a port is removed from the manifest, naming the include and the line to add.
• The check runs before the Continuous Linux build, so a missing port fails in seconds and not after the compile.

• The port is declared rather than the decimal type reimplemented. The dependency is deliberate: the commit chose exact base-ten arithmetic and wrote down why, and a decimal that rounds in binary is the defect that decision exists to prevent.
• The check reads the ports' own manifests for the dependency closure instead of keeping a list of libraries that arrive transitively. A list would have to be right about Boost's graph, and the first time it was wrong it would pass a missing port in silence – which is the failure mode this story exists to close.
• The check runs before the build on Continuous Linux rather than on the pull request. A pull-request check would have to fetch the vcpkg submodule in a workflow that does not currently, which is a CI design decision rather than part of this fix; the task records that option.
• The dependency is declared in two places, and the first task found only one of them. vcpkg.json makes the port install; the root find_package(Boost ... COMPONENTS ...) is what the estate uses to say which Boost libraries the project builds against, and what CMake checks before compiling anything. The second task adds it there, which is also what makes a missing port fail at configure time with the component's name instead of as a missing header after the compile has started. Every header-only library already in that list is declared this way and is not linked, so no link line changed.

• Non-Boost third-party dependencies. The check reads boost/ includes only; sqlgen, reflectcpp or immer landing without a manifest entry would still reach CI. A general check needs a header-to-port map that does not exist for those libraries.
• A pull-request-time build, which is the gate that would have caught this without any check at all. It costs a vcpkg install per pull request.