feat!: deploy and manage frontends in local development

[subnetmarco]

Summary

Second of three stacked PRs for volcano deploy; based on PR1.

• volcano frontends now targets the local development server: deploy, list, get, redeploy, delete, logs, and routes. The local server already builds and serves frontends at <id>.frontends.localhost:8080, but the CLI had no way to reach it.
• a local frontends deploy notes on stderr that it deploys to local development and names volcano cloud frontends deploy, so a script still on the old alias sees the target change
• a local frontends deploy prints the site URL. A new frontend has no URL until its first build finishes, so it prints the frontends get command that shows it instead. Cloud output is unchanged.
• function routes work locally, since the local server serves them. Custom domains stay a cloud command; locally they refuse and name volcano cloud frontends domain ....
• docs/frontends.md and docs/project-configuration.md describe both modes

Breaking: volcano frontends ... was a hidden, deprecated alias for volcano cloud frontends .... It now acts on the local server; scripts that relied on the alias must use volcano cloud frontends ....

Merge order: land #296 on main first, then retarget this PR to main before squashing, so the feat! title reaches main and release-please records the breaking change.

Verification

• make lint
• go test ./...
• local-mode E2E against kong/volcano:local-nightly. The frontends scenario deploys a Next.js app locally, checks the URL hint, serves it, and redeploys it. It reads the build logs (asserting next build), creates a function route, fetches it through the frontend, deletes the route, and deletes the frontend.
• builds and passes go test ./... on its own, without PR3

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[subnetmarco]

Looks good. The local tree reuses the cloud subcommands, and the domain/routes refusals follow the existing cloud-only pattern. The local-mode E2E covers the whole lifecycle, including a scoped NEXT_PUBLIC_* value reaching the build. Because of bump-minor-pre-major, feat! only bumps to 0.45.0, which seems right for retiring a hidden alias.

Two small things:

• docs/project-configuration.md: the local path ends on the cloud config command (see the inline comment).
• Optional: a script that still uses the old alias, run with no local server, gets the generic "run volcano start" error. A hint naming volcano cloud frontends ... on that error would make the break self-explanatory. The deprecation warning has been out for a while, so this is fine to skip.

[subnetmarco]

Fixed the project-configuration.md sentence. I skipped the alias hint: when no local server is running, the error already ends with "or use 'volcano cloud ' to target your cloud project", so a script on the old alias is pointed at the cloud tree.

[swkeever]

Approving. Making root frontends local matches the other resource commands, and the break is documented in the footer, PR body, and docs. Local frontend support is on hosting main, and localmode-e2e passed against the nightly image.

Merge order: land #296 on main first, then retarget this PR to main before squashing. If it's squashed into refactor/deploy-entrypoints, the feat! title disappears into #296's refactor: commit and release-please won't record the breaking change or bump the version.

Non-blocking:

• With volcano start running, a script still on the old alias now deploys, lists, or deletes local frontends and exits 0. Deploy output doesn't say "local" for a new frontend. The no-server error points to cloud, but this case gets no signal. A one-line stderr note naming the target on local frontends deploy would cover it.
• frontends delete --help in the local tree still says "Delete a frontend from the current cloud project." (internal/cmd/frontends/delete.go:31).
• Follow-up: volcano-skills AGENTS.md (~L307) and its copies in volcano-agentic-plugins still call volcano frontends ... a deprecated alias.