The whole operations/ tree (site-move, server-rename, drained-sites, plan) is unreachable from the published package

dist/deploy/site-ports.d.ts is published, but no JavaScript behind it is. The module's own doc comment tells callers to use it, the package's "./*" wildcard export makes the import resolve for TypeScript, and then it throws at runtime.

Reproduction

Both 0.12.4 (installed) and 0.12.7 (fetched from the registry):

$ ls package/dist/deploy/ | grep site-ports
site-ports.d.ts

$ grep -rl "buildHostSitePortsScript" package/dist/
package/dist/deploy/site-ports.d.ts

$ grep -rl "buildHostSitePortsScript" --include="*.js" package/dist/
(nothing)

The symbols are absent from every emitted chunk, not just from a barrel:

$ grep -rohE '\b(occupiedHostPorts|buildHostSitePortsScript|parseHostSiteFragments|allocateSitePorts|parseUpstreamPort)\b' package/dist/ --include="*.js"
(nothing)

And the runtime resolution fails outright:

await import('@stacksjs/ts-cloud/deploy/site-ports')
// Cannot find module '@stacksjs/ts-cloud/deploy/site-ports'

deploy/index.d.ts re-exports ./site-target but not ./site-ports, so the root and /deploy entries do not carry them either.

Why this is worth fixing rather than working around

The affected exports are exactly the ones a co-tenancy-aware tool needs, and the module's own documentation points at them:

Build it with occupiedHostPorts() from ./site-ports, passing the deploying project's own slug as ignoreSlug

ValidateDeploymentOptions.occupiedPorts documents that call as the supported way to make validation co-tenant-aware. Following it does not work.

The failure mode is the bad kind: because the .d.ts is shipped and the "./*" export pattern maps the subpath, tsc accepts the import. Nothing surfaces until the code runs.

What was blocked

stacksjs/stacks#2378 (buddy cloud:sites) reads each box's rpx registry to list what every project on it serves. buildHostSitePortsScript + parseHostSiteFragments are precisely that read, already written and already tested here. Since they are not loadable, that PR carries a duplicate of both, with a comment to delete it once this is fixed.

That duplication is the cost worth avoiding: site-ports.ts deliberately duplicates HOST_SITES_DIR from rpx-gateway.ts and pins the copy with a test so it cannot drift. A copy in another repository gets no such test.

Suggested fix

Re-export ./site-ports from deploy/index.ts so the runtime lands in the bundle and the symbols are reachable from @stacksjs/ts-cloud/deploy, the same way site-target already is.

Worth a check for other files in the same state: a .d.ts with no reachable JS is silent, and the "./*" wildcard means every one of them looks importable.