pack: a public folder over the output file limit stops the deploy before anything is sent

[enesismail]

What was wrong. Astro copies the public folder into the built site whole, dotfiles included, so the number of files in that folder is a floor on the number in the site. A project with more than 1,000 files there passed every local check, uploaded, built, and was then refused for producing more files than a site may hold. The answer was available on the user's own machine, for nothing.

Measured once before building the stop, because a wrong floor would be a refusal with no way past: Astro 7.3.5 on a project with 1,001 tiny files under public/ (nested two deep, one a dotfile) and one page built 1,004 files, every one of the 1,001 present byte for byte.

What changes.

• A new hard stop, limit-public-files, with its own check and failure id so that one id names one number. It refuses a public folder holding more than MaxOutputFiles (strictly more, as the server does: exactly 1,000 passes).
• The count is made inside Limits over the walk's own list, under the public folder the deploy resolved from the config. Files the walk excluded are not counted and the disk is not read a second time. Which files sit under the folder is asked of the function the file-name check already uses, so a sibling such as public-old/ cannot be counted by one and not the other.
• The message names the folder, its count and the limit, then the folder's own busiest directories; the next step is to move what the site does not serve out of the folder or ignore it. A project whose public folder is its root is told to point publicDir somewhere narrower instead.
• When the config's publicDir cannot be read, the existing warning now says the default folder was the one checked and counted, and it sits beside the stop.
• The README's output-limits paragraph and CLAUDE.md say the public folder is counted locally while everything else the build emits is still the server's to count, and the deploy tool's description names the new refusal. MaxOutputFiles is bound in the README test; the troubleshooting entry and the failure catalog gain the new id.

Rows (written before the finding existed, and red against a stub that answered the row with no finding):

• 1,001 under public/, nested, with a dotfile: one hard stop naming 1,001 and 1,000, never the whole tree's count. 1,000: no finding.
• 1,001 under public-old/: no finding. A configured static/ over the limit: refused and named; public/ over the limit while static/ is configured: no finding.
• Public folder .: the whole walked tree is counted, 1,001 refused and 1,000 not, and the finding says the project itself is the folder.
• The busiest directories listed are the folder's own.
• A real walk with 1,000 files plus one the ignore file drops: no finding.
• The 3,400-file public tree reports both the source count and the public count, and every limit row is answered.
• End to end through the deploy: the default folder, a configured folder and the unreadable-config fallback are each refused with nothing sent; the control at 1,000 reaches the network.

Mutations, each run and reverted: count the whole tree; >= for >; a prefix match without the separator; ignore the folder argument; state the whole tree's count; rank directories over the whole tree; downgrade to a warning; decline the manifest row; have the deploy pass a fixed public; word the root's finding as a named folder's; the README figure off by one. Each reds the row its comment names.