A re-registration from a legacy CVM carries port_attrs=None, which
previously wiped any value learned at an earlier registration or lazy
fetch. Gateway restart + CVM re-register would then force a redundant
Info() fetch. Keep cached attrs unless the caller actively reports new
ones; same instance_id implies same compose_hash, so the cache cannot
go stale.

Same instance_id with a different compose_hash means the app was
upgraded in place (typical for KMS-provisioned CVMs that reuse their
disk). Previously, a legacy-style re-registration (port_attrs=None)
would preserve stale cached attrs across such upgrades because the
gateway assumed instance_id ↔ compose_hash was stable.

Track the compose_hash each cached port_attrs was learned against
(taken directly from the attested AppInfo, not from client input).
Mismatch clears the cache so the lazy Info() fetch runs again.

When a CVM registers without port_attrs (legacy CVM, or compose_hash
mismatch invalidated the cache), enqueue a background fetch right away
instead of waiting for the first proxied connection to discover the
miss. Reduces the window during which the fast path returns a wrong
`pp = false` because the cache hasn't been populated yet.

The fetcher dedupes in-flight ids, so this is safe to enqueue on every
registration that ends up without cached attrs.

Right after registration, the WireGuard handshake hasn't completed yet
and the agent's TCP port isn't reachable. The previous one-shot fetch
would fail and leave the cache empty, falling back to pp=false until
the next connection (which would itself eat one more failed fetch).

Move the timeout/retry policy into a dedicated config block so it can
be tuned per deployment:

  [core.proxy.port_attrs_fetch]
  timeout = "10s"          # per-attempt Info() RPC timeout
  max_retries = 5          # extra attempts after the initial try
  backoff_initial = "1s"   # doubles each retry up to backoff_max
  backoff_max = "30s"

Worst-case 1+2+4+8+16+30 ≈ 1 min covers a reasonable WG warmup window.

Bail out early when the instance is no longer in state (recycled while
queued) — the unknown-instance error chain is the signal.

Don't waste a 1-minute retry budget on errors that can't recover. Two
classes:

- Transient → retry: TCP/RPC failure, Info() timeout. The CVM may just
  be warming up.
- Permanent → bail: instance was recycled (no longer in state), tcb_info
  isn't valid JSON, missing app_compose key, or app_compose itself
  fails to parse. Same input each retry, same failure.

`tcb_info` empty (public_tcbinfo=false) still goes through the success
path with an empty map cached, as before — that's not a fetch failure.

Thread the new gateway config knobs through the dstack-app deployment:

- .env / .app_env gains `INBOUND_PP_ENABLED` (default false). Set to
  true only when the gateway runs behind a PP-aware L4 LB; otherwise
  every connection would be rejected because the parser would try to
  read a PP header that isn't there.

- docker-compose.yaml forwards the new env vars plus the retry/backoff
  knobs for the background port_attrs fetcher and the pp_header read
  timeout.

- entrypoint.sh writes the corresponding fields into gateway.toml,
  including the new [core.proxy.port_attrs_fetch] section.

Defaults match the in-repo gateway.toml so existing deployments
continue to work without any .env changes.

Co-authored-by: Copilot <[email protected]>

The pre-existing script had three latent issues that weren't checked
because the file hadn't been touched. Modifying it for the PP rollout
brings it into the prek diff, so fix them now:

- SC1091: `source .env` — explicitly mark dynamic include
- SC2002: replace `cat … | tr …` with `tr … < file` redirect
- SC2086: quote $WG_ADDR in the cut pipeline

Apps can now declare `port_policy.restrict_mode: true` in app-compose to
make the gateway reject connections to any port not listed under
`port_policy.ports`. Combined with this PR's existing PROXY protocol
support, this gives apps explicit control over which ports the gateway
will forward.

Implementation:

- `AppCompose` gets a single nested `port_policy: PortPolicy` field
  (replacing the flat `ports` field added earlier on this branch).
  Keeps related config grouped and gives `restrict_mode` a meaningful
  namespace instead of a vague top-level flag.
- Gateway internals collapse the previous `port_attrs: Option<BTreeMap>`
  + `port_attrs_hash: String` into a single `Option<PortPolicy>`
  carrying `{ ports, restrict_mode }`. One Option distinguishes
  "not reported" from "reported empty" cleanly.
- RPC: `RegisterCvmRequest.port_attrs` (PortAttrsList) becomes
  `port_policy` (PortPolicy { ports, restrict_mode }).
- Enforcement: `filter_allowed_addresses` runs before
  `connect_multiple_hosts` in both TLS-terminate and TLS-passthrough
  paths. A denied connection bubbles up as a normal error and the
  proxy closes the inbound TCP stream — no special HTTP response.
- Failure mode: fail-close. An unknown policy (cache miss) denies the
  connection and triggers a background fetch, so subsequent connections
  proceed once the policy is known. Apps that opt into restrict_mode
  must run a CVM that reports policy at registration time; legacy
  CVMs that fall back to the lazy `Info()` fetch get the open default
  (`restrict_mode = false`) so they keep working.
- Unknown instance_ids (e.g. the `localhost` shortcut) bypass the
  check — the policy machinery only applies to registered CVMs.
- Rename the lazy-fetch config block from `port_attrs_fetch` to
  `port_policy_fetch` for consistency (only ever shipped on this
  unmerged branch).

Tests:

- 4 new unit tests covering allow/deny, disabled mode, fail-close on
  unknown policy, and the unknown-instance bypass.
- Snapshot tests updated for the renamed fields.