Does top-level public/ bypass the container catch-all and Fluid Compute?

I am running a PHP 8.3 + Apache application using Dockerfile.vercel with Fluid Compute in syd1.

Observability shows that static requests such as /assets/*, images, favicons, robots.txt, and sitemap.xml are currently invoking the container /index route.

This is significant because the project is consuming around 16–18 GB-Hrs/day of Fluid Provisioned Memory, despite actual application memory usage being only around 227–239 MB and Active CPU being very low.

Vercel's automated guidance suggested that placing static files in a top-level public/ directory should cause them to be deployed to Vercel's CDN and take precedence over the automatic Docker container catch-all rewrite.

I would like to confirm the behaviour specifically for Dockerfile.vercel / container-image projects:

Does public/assets/image/test.png get served directly by Vercel's CDN at /assets/image/test.png without invoking the container?
Do public/robots.txt, public/favicon.ico, and public/sitemap.xml also bypass the container completely?
Does this work automatically without adding vercel.json rewrites?
Is static-file matching evaluated before the automatic /(.*) container rewrite?
Has anyone verified this with Runtime Logs / Fluid Compute usage on a container-image deployment?

I am testing this safely on a preview branch first with a single file:

public/vercel-static-test.txt

The intended result is for /vercel-static-test.txt to return 200 from the CDN without appearing as an /index function invocation.

Any confirmation from someone using Dockerfile.vercel container images would be appreciated.