fix(favicon): revert marketing-ISR-breaking force-dynamic, fix manifest env-tint

Addresses the fourth round of review findings on PR #5588:

- Cursor (High, confirmed via testing, not just code review): the
  previous commit's `export const dynamic = 'force-dynamic'` on
  app/layout.tsx would have forced the entire marketing site
  ((landing) route group - blog/library posts, changelog, solutions
  pages, all with their own `revalidate` exports) into per-request
  rendering, breaking their Lighthouse/LCP budget. My earlier "verified
  via build, no regression" claim was itself wrong: my local build
  masked this because NEXT_PUBLIC_APP_URL=localhost makes isHosted()
  false, which makes app/layout.tsx render next-runtime-env's
  RuntimePublicEnvScript - which unconditionally calls
  unstable_noStore() - already forcing marketing pages dynamic before
  my change even ran, for a completely unrelated pre-existing reason.
  Rebuilt with NEXT_PUBLIC_APP_URL=https://www.sim.ai (matching real
  hosted deployments, isHosted() true, the safe script path) to get an
  unmasked answer: confirmed force-dynamic was the actual regression
  (marketing pages went from ● to ƒ), and confirmed the revert restores
  them to ○ with their normal 1h revalidate window. Documented the
  accepted tradeoff instead: marketing-page favicon metadata may lag
  by up to one revalidate window after a deploy (bounded, self-healing
  at the next ISR regeneration, which runs in the live server process
  after bootstrap.ts has loaded secrets) - the actual workspace app
  (this feature's real audience) is already fully dynamic today
  (session/auth), so it needs no explicit marker.

- Cursor (Medium): app/manifest.ts's non-whitelabeled branch still
  hardcoded production favicon paths instead of ICON_SETS[getDeploymentEnv()],
  so PWA install/home-screen icons stayed production-tinted while the
  HTML favicon was correctly env-tinted. Now uses the same per-tier set.

Author: waleedlatif1

apps/sim/app/layout.tsx

@@ -24,33 +24,28 @@ export const viewport: Viewport = {
   ],
 }
 
-/**
- * Forces every route under this layout to render dynamically. Every real page
- * in this app already renders dynamically today (session/workspace state), so
- * this changes nothing currently — but it's the difference between "happens
- * to be true" and "guaranteed": {@link generateBrandedMetadata} reads
- * `getDeploymentEnv()` for the favicon set, which depends on `process.env`
- * being populated by `bootstrap.ts`'s runtime secrets load, and
- * `generateMetadata()` alone does not force per-request evaluation — Next
- * still prerenders it at build time for any route that's otherwise static or
- * ISR-eligible. Without this, a future static/ISR page added under this
- * layout would silently get build-time (production-tier) favicon metadata
- * baked in, with no error. Matches the `force-dynamic` already declared on
- * `app/manifest.ts` and `app/api/favicon/route.ts`.
- */
-export const dynamic = 'force-dynamic'
-
 /**
  * Not a static `export const metadata` object: {@link generateBrandedMetadata}
  * reads `getDeploymentEnv()` for the favicon set, which depends on
  * `process.env` being populated by `bootstrap.ts`'s runtime secrets load. A
  * static object is resolved once at module-evaluation time and Next.js treats
- * it as truly constant (eligible for build-time resolution on any
- * statically-rendered route sharing this layout) — `generateMetadata()`
- * forces the same per-request resolution `app/api/favicon/route.ts` already
- * uses. Paired with the `dynamic = 'force-dynamic'` export above, which
- * guarantees that resolution actually happens per-request rather than only
- * "happening to" because every current page is otherwise dynamic.
+ * it as truly constant (eligible for build-time resolution) —
+ * `generateMetadata()` at least makes resolution part of the page's own
+ * render rather than a frozen module-level value.
+ *
+ * Deliberately NOT paired with `export const dynamic = 'force-dynamic'` on
+ * this (root) layout: every `(landing)` marketing page sets its own
+ * `revalidate` and relies on being statically generated /
+ * incrementally revalidated for its Lighthouse/LCP budget (see
+ * `app/(landing)/CLAUDE.md`) — forcing the root layout dynamic would force
+ * the entire marketing site dynamic too, which is a much larger regression
+ * than a favicon staying on its previous tier for up to one revalidate
+ * window after a deploy. The actual workspace app (this feature's real
+ * audience) is already fully dynamic today (session/auth), so
+ * `generateMetadata()` already resolves per-request there without needing
+ * the marker. Marketing pages accept bounded staleness instead: the favicon
+ * self-corrects at the next ISR regeneration, which runs in the live server
+ * process (after `bootstrap.ts` has loaded secrets), not at build time.
  */
 export function generateMetadata(): Metadata {
   return generateBrandedMetadata()

apps/sim/app/manifest.ts

@@ -1,10 +1,12 @@
 import type { MetadataRoute } from 'next'
-import { getBrandConfig } from '@/ee/whitelabeling'
+import { getDeploymentEnv } from '@/lib/core/config/env-flags'
+import { getBrandConfig, ICON_SETS } from '@/ee/whitelabeling'
 
 export const dynamic = 'force-dynamic'
 
 export default function manifest(): MetadataRoute.Manifest {
   const brand = getBrandConfig()
+  const icons = ICON_SETS[getDeploymentEnv()]
 
   return {
     name:
@@ -21,26 +23,16 @@ export default function manifest(): MetadataRoute.Manifest {
     theme_color: brand.theme?.primaryColor || '#33C482',
     orientation: 'portrait-primary',
     // A whitelabeled deployment's install/home-screen icon should be the
-    // tenant's own brand, not Sim's — same precedence as the HTML favicon
-    // slots in generateBrandedMetadata() (ee/whitelabeling/metadata.ts).
+    // tenant's own brand, not Sim's; otherwise it's the same per-environment
+    // set as the HTML favicon slots in generateBrandedMetadata()
+    // (ee/whitelabeling/metadata.ts), so a staging/dev PWA install doesn't
+    // look like prod either.
     icons: brand.faviconUrl
       ? [{ src: brand.faviconUrl, sizes: 'any', type: 'image/png' }]
       : [
-          {
-            src: '/favicon/android-chrome-192x192.png',
-            sizes: '192x192',
-            type: 'image/png',
-          },
-          {
-            src: '/favicon/android-chrome-512x512.png',
-            sizes: '512x512',
-            type: 'image/png',
-          },
-          {
-            src: '/favicon/apple-touch-icon.png',
-            sizes: '180x180',
-            type: 'image/png',
-          },
+          { src: icons.android192, sizes: '192x192', type: 'image/png' },
+          { src: icons.android512, sizes: '512x512', type: 'image/png' },
+          { src: icons.apple, sizes: '180x180', type: 'image/png' },
         ],
     categories: ['productivity', 'developer', 'business'],
     shortcuts: [