deploy_component: validate declared entry points survived extraction

## Context
harper#1718 fixes the root cause of `harper deploy` silently shipping a truncated tarball (a dangling symlink made tar-fs's dereferenced walk finalize the archive early with no error — see that PR / DESIGN.md for the full mechanism).

That fix closes the specific truncation cause, and adds a CLI-side warning when packaging has to skip a dangling symlink. But `deploy_component` still never validates, post-extract, that the declared entry points (`jsResource`, `graphqlSchema`, etc.) actually exist on disk — so any *other* future cause of a truncated/incomplete extraction would still report "Successfully deployed" silently.

This gap matters most for the **server-side path**: `package_component`/`deploy_component` initiated on the server (not via the CLI) has no equivalent warning surface at all — the CLI's stderr message is the only place omitted content becomes visible today.

## Proposed fix
After extraction, validate that the component's declared `jsResource`/`graphqlSchema` globs (and any other declared entry points) still resolve to real files, and fail the deploy loudly if not — rather than reporting success on an incomplete install.

Cross-model review (Gemini + Harper-domain adjudication) on #1718 recommended this as a follow-up rather than folding it into that PR, since it's a distinct, larger change (server-side, config-aware, post-extract) orthogonal to the packaging root cause.

Read the context in #1718 and DESIGN.md, then trace the server-side package_component/deploy_component flow through extraction. Identify where declared jsResource, graphqlSchema, and other entry-point globs are available for post-extract validation. Done means incomplete extraction causes deploy to fail loudly instead of reporting success.

Written by the indexing model from the issue text.