Add a constructor step to record conda-ship installation metadata

## Use case

A constructor-based distribution may include a prebuilt executable produced by conda-ship, such as a standalone `conda` executable.

The executable already knows how to bootstrap its managed prefix, including from an embedded bundle for offline installation. This issue is not about air-gapped installers or choosing a conda-ship artifact layout.

The missing integration is to record who may replace the installed executable later. For a standalone `conda` runtime, this is the outer executable installed by constructor, not the `conda` package inside its managed prefix. A later `conda self update` needs to know whether the runtime may replace that executable itself or whether an external installer owns it and should provide the user with an installer-specific update instruction.

## Existing conda-ship interface

conda-ship provides the local `v1/record-installation` helper. An installer invokes the installed executable once to record these values in the existing `.RUNTIME_NAME.json` file:

- installation label, such as `constructor`
- ownership, either `direct` or `external`
- stable installed executable path
- optional update instruction for external ownership

This does not require a constructor-specific metadata format or different executable bytes.

## Possible constructor integration

When a constructor-based distribution needs this, add a construct option that invokes `v1/record-installation` after installing the executable. If the metadata is required for correct update behavior, the invocation must be part of the installer rather than a user post-install script because user scripts can be disabled.

The first consumer should determine which constructor backends and fields are actually needed. The earlier draft in #1300 attempted SH, PKG, EXE, and MSI support without a downstream consumer and was closed.

## Status

There is no concrete constructor-based consumer yet, so implementation is deferred until one has a construct file and a defined executable update model. Homebrew and Python installer detection are separate work tracked in jezdez/conda-runtime#15.

Start by identifying a concrete constructor-based consumer and its construct file, then inspect the conda-ship v1/record-installation interface. Determine which constructor backend and fields the consumer needs, and define completion as installer-time metadata recording with a documented executable update model.

Written by the indexing model from the issue text.