fix(aspire): plugin API resources still pin host ports 8091–8094

[rickylabs]

Summary

Split out of #952 / PR #978, which made host-port pinning opt-in for the example service and the app.
Plugin API resources were deliberately left pinned and still carry the same defect: two workspaces
that both install plugins collide on :8091–:8094, and aspire start --isolated cannot randomise
those ports away.

Why it was not fixed in #978

The scaffold.runtime E2E suite live-probes those exact ports:

• packages/cli/e2e/src/application/gates/scaffold/runtime-gates.ts L140–L235 probes
  http://127.0.0.1:8091/health/live, :8092/api/v1/sagas/sagas, :8093/health, :8094/health/live
• and passes --allow-net=127.0.0.1:8091,127.0.0.1:8092 into the generated project.

Roughly 20 tutorial and explanation passages under docs/site/** also curl those ports.

What has to land first

1. The scaffold.runtime gates resolve each plugin resource's endpoint from the Aspire resource
   service (or the dashboard API) instead of hardcoding 127.0.0.1:<port>, including the
   --allow-net grant they hand to the generated project.
2. The docs move from "curl :8091" to "read the URL the dashboard shows".

Then

Drop Port from the plugin entries the scaffolder writes. The generator seam already exists —
packages/cli/src/kernel/templates/aspire/helpers/register/render-http-endpoint.ts emits
{ env: 'PORT' } whenever an entry carries neither HostPort nor Port, and
generate-register-plugins.ts already calls it. This is a scaffold-side change plus the two
prerequisites above.

Refs #952