fix(stx): resolve project components from nested views + apply defineProps defaults in SSR

Problem

Two SSR gaps in renderComponentWithSlot (packages/stx/src/utils.ts) surfaced while building a real multi-page storefront:

1. Nested-view component resolution — the resolver searched the calling file's <dir>/components, the global componentsDir (framework defaults), and src/components / components fallbacks, but never the canonical project resources/views/components. Project components resolved for root-level views (e.g. resources/views/index.stx) yet 404'd for any view in a subdirectory (e.g. resources/views/products/index.stx, checkout/*, policies/*).

2. defineProps defaults during SSR — a component's <script> is evaluated client-side only, so destructuring defaults like const { steps = [...] } = defineProps() were undefined at server-render time. Any @foreach//:prop relying on a default (a prop the caller omitted) broke — including the shipped Storefront/CheckoutSteps (@foreach (steps ...) → "steps is not iterable"), plus custom header/footer nav defaults.

Fix

1. Add resources/views/components (and the legacy resources/components) to the project-wide fallback search dirs, so project components resolve from any view depth — matching how framework defaults already resolve globally.

2. Add a best-effort applyDestructuredPropDefaults() pass that parses a component's defineProps destructuring defaults and fills only the keys the caller didn't provide (caller-provided props always win). Wrapped in try/catch — any parse/eval failure leaves the context exactly as before.

Both changes are additive and backwards-compatible.

🤖 Generated with Claude Code