chore(dev): harden Community JCEF local runtime

[openai0229]

Related issue

Closes #2709

Depends on #2711. Review and merge #2711 first.

Summary

This PR makes the Community JCEF development launcher wait for the actual desktop window instead of stopping at HTTP health checks. On macOS it creates a temporary app image with the configured JBR and JCEF frameworks, launches that executable, and waits for a ready marker written after the JFrame becomes visible.

Community CORS accepts arbitrary origins only under the Spring dev profile so an isolated frontend can connect to the local backend. Release behavior keeps the existing origin allowlist. Task lifecycle and application-exit coordination are intentionally excluded from this PR.

Affected surfaces

• Frontend / Web
• Backend / API / Storage
• Database plugin / Driver
• JCEF / Desktop packaging
• CI / Build / Release
• Documentation only

Verification

• Commands and results:
  • bash -n script/dev-community-jcef.sh: passed.
  • mvn -pl chat2db-community-web -am -Dtest=CorsFilterTest -Dsurefire.failIfNoSpecifiedTests=false -Dmaven.test.skip=false test: passed; CorsFilterTest ran 2 tests with no failures.
  • mvn -pl chat2db-community-jcef -am -Dmaven.test.skip=false -DskipTests package: passed, proving this PR compiles independently of the Task PR.
  • git diff --check refactor/community-workspace-desktop-ui...HEAD: passed.
• Manual verification: the launcher flow was exercised during the original PR work with separate frontend and JCEF processes on macOS.
• UI evidence: N/A; this is development-runtime plumbing.

Risk and compatibility

• Public API or stored data: no public API or stored-data changes.
• Database or driver compatibility: no database or driver behavior changes.
• Network, privacy, or security: arbitrary origins are accepted only when the dev profile is active; release profiles retain the Community allowlist.
• Community / Local / Pro boundary: changes are limited to Community development startup and the shared JCEF frame ready marker.
• Backward compatibility: non-macOS keeps the existing direct Java launch path.

Reviewer map

• Start here: script/dev-community-jcef.sh, CorsFilter, and MainJFrame.writeDesktopReadyMarker.
• Failure condition: release CORS becomes permissive, macOS starts without required JCEF frameworks, temporary app images leak, or the script reports success before the desktop window is visible.
• Rollback or disable path: revert this PR and use the previous raw-jar launcher.

Contributor declaration

• I linked the Issue that defines this change.
• I tested the affected behavior and reported the actual results above.
• I did not include credentials, private data, or generated build output.
• I disclosed substantial AI assistance below, or this PR contains no substantial AI-generated code.

AI assistance: Substantial AI assistance was used for implementation, debugging, tests, and review. The contributor manually reviewed and tested the resulting behavior.

[github-actions]

Reviewed 5cf7dbe. Findings: 0 critical, 0 high, 1 medium. Merge recommendation: non-blocking; address the macOS temporary app-image cleanup to prevent persistent build artifacts and disk growth. Coverage was limited to the current GitHub diff, pull request metadata, existing review history, and relevant repository packaging sources; no tests or runtime checks were run.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by AI Pull Request Reviewer for #2714 · 25.1 AIC · ⌖ 0.786 AIC · ⊞ 17K

[github-actions]

[medium] The macOS launcher moves the generated app image out of the staging directory into jpackage/output/dev-community-jcef, but cleanup() only removes MAC_DEV_STAGING_DIR. Every successful macOS launch, timeout, or later process exit therefore leaves the full generated app image in the working tree, contrary to the temporary-image lifecycle and consuming substantial disk space until the next run. Keep the app image inside the staging directory, or explicitly remove MAC_DEV_OUTPUT_DIR from the exit trap after the launched process has terminated.