Published 0.7.423 packages declare `types` but ship no .d.ts files

## Summary

As of `@hcengineering/*@0.7.423`, the published npm tarballs reference a TypeScript
declaration entry point that is not included in the package. Every package's
`package.json` sets `"types": "types/index.d.ts"`, but the tarball contains no
`types/` directory and no `.d.ts` files at all — only the compiled `lib/*.js`
(plus sourcemaps), `package.json`, and `tsconfig.json`.

This makes the packages effectively untyped for consumers. Any TypeScript project
that imports them under `strict` / `noImplicitAny` fails to compile.

This is separate from (and newly surfaced by) the `workspace:` protocol fix in
#10773 — that fix correctly unblocked clean-room `npm install`, and the install now
resolves the full tree. The missing declarations are the next blocker downstream.

## Reproduction

```console
$ npm view @hcengineering/tracker@0.7.423 types main
types = 'types/index.d.ts'
main = 'lib/index.js'

# Inspect the actual published tarball:
$ curl -sL "$(npm view @hcengineering/tracker@0.7.423 dist.tarball)" -o tracker.tgz
$ tar tzf tracker.tgz | sed -E 's#package/([^/]+/?).*#\1#' | sort -u
lib/
package.json
tsconfig.json

$ tar tzf tracker.tgz | grep -c '\.d\.ts$'
0
```

The declared `types: types/index.d.ts` points at a path that does not exist in the
tarball.

## Consumer-side error

```
error TS7016: Could not find a declaration file for module '@hcengineering/tracker'.
'.../node_modules/@hcengineering/tracker/lib/index.js' implicitly has an 'any' type.
```

## Scope

Not limited to `tracker`. Confirmed identical for `core`, `contact`, `rank`, `tags`,
`text-markdown`, `account-client`, `collaborator-client` (and presumably the rest of
the `@hcengineering/*` set at `0.7.423`): each declares `types: types/index.d.ts`
and ships zero `.d.ts` files.

## Expected

Either:

1. Include the generated declaration files (`types/**/*.d.ts`, or `lib/**/*.d.ts`
if you co-locate them) in the published tarball — i.e. add the directory to the
package `files` allowlist / remove it from `.npmignore`, and ensure the build
emits declarations before `npm publish`; or
2. If the packages are intentionally shipped without types, drop the `types` field
from `package.json` so the failure mode is clear rather than a dangling reference.

(1) is presumably the intent given the `types` field is present.

## Environment

- `@hcengineering/*@0.7.423` (latest)
- npm registry tarballs (clean-room, no workspace checkout)
- TypeScript 5.9, ts-node 10.9, `strict: true`

Start by inspecting the affected packages' package.json and tsconfig.json, then trace the build and npm publish configuration. Reproduce the tarball listing and strict TypeScript consumer error described in the issue. Done means the published packages either contain the declared .d.ts files and compile for consumers, or no longer declare a missing types entry.

Written by the indexing model from the issue text.