Simple `mountApp()` example from the Discord

closes#3391 ---Generated PR message:Fix base path handling for assets in plugin-viteFixes issue where Fresh apps mounted at non-root paths (e.g., /ui) inframeworks like Hono would fail to load assets correctly.  ProblemWhen mounting a Fresh app with app.mount('/ui', UI.fetch), the HTMLwould load but all assets (CSS, JS, images) would return 404 becauseasset pathswere hardcoded to start with /assets/ instead of respecting the Vitebase configuration.  Solution- Modified packages/plugin-vite/src/plugins/server_entry.ts to readVite's base config and apply it to asset paths- Added getAssetPath() helper function to construct proper asset URLswith base path  - Updated both CSS and asset file registration to use the base path  TestingAdded comprehensive test case "vite build - base path asset handling"that:  - Builds demo with custom base path /my-app/  - Verifies generated server.js contains correctly prefixed asset paths  - Follows existing test patterns and utilities  Usage  Users can now properly mount Fresh apps by configuring both:```ts  // vite.config.ts  export default defineConfig({    base: "/ui/",    plugins: [fresh()],  });  // main.ts    const app = new App({ basePath: "/ui" });  // hono-app.ts  app.mount('/ui', UI.fetch); // Assets now work correctly```  Backward compatible - no changes needed for apps mounted at root path.

I noticed that in#3393 it looks like it's possible thatthe "Copied"/Check icon will be shown even if copying to clipboardfails.This PR changes it so that the Check icon only shows if copy succeeds.

Ultimately, it causes more problems than it solves.

closes#3383

- Show help text when `-h` or `--help` is passed to `@fresh/init`- Print current version for `@fresh/init` during `--help`<img width="367" height="95" alt="image"src="https://github.com/user-attachments/assets/e3318fae-ce8a-4cbb-bb0a-78f338f1b3a2"/>- Refresh `--help` text with colors similar to `deno -h`; + "Freshbranding" style for the `@fresh/init` text- Print `@fresh/core` version when `@fresh/init` runs<img width="471" height="88" alt="image"src="https://github.com/user-attachments/assets/1a0bd619-315d-4abb-889c-ec6eb3a9b45f"/>I think showing versions is helpful for verifying/debugging what Freshversion will be installed during init before all files are generated.## Comparisons### `@fresh/init` + empty project name#### Before<img width="1104" height="615" alt="image"src="https://github.com/user-attachments/assets/b1534bb5-eecc-4692-9977-df3903868416"/>#### After<img width="1169" height="695" alt="image"src="https://github.com/user-attachments/assets/6a743d79-bb59-463a-aadd-fbf734149258"/>### `@fresh/init --help`#### Before<img width="1007" height="150" alt="image"src="https://github.com/user-attachments/assets/0ad42078-420c-4dc6-9561-4a338cc09741"/>#### After<img width="1272" height="579" alt="image"src="https://github.com/user-attachments/assets/3dfe6712-8604-4429-a418-5e6538117303"/>

Fix for mountApp() with the new basePath handling---Generated PR message:I successfully investigated and implemented a fix for mountApp() to makeit compatible with basePath handling. Here's what I found and fixed:  The ProblemThe original mountApp() implementation completely ignored the innerapp's basePath. When mounting an app like this:```ts  const innerApp = new App({ basePath: "/api" })    .get("/users", () => new Response("users"));  const app = new App()    .mountApp("/v1", innerApp);```The route would become /v1/users instead of the expected /v1/api/usersbecause the inner app's /api basePath was lost.  Root CauseThe issue was in the mountApp() method at packages/fresh/src/app.ts:333.The original code only used:```ts  pattern: mergePath(path, cmd.pattern, true)```This only considered the mount path (/v1) and the command pattern(/users), but ignored app.config.basePath (/api).  The FixI modified the mountApp() method to properly handle the inner app'sbasePath:```ts  // Apply the inner app's basePath if it exists  let effectivePattern = cmd.pattern;  if (app.config.basePath) {    effectivePattern = mergePath(app.config.basePath, cmd.pattern, false);  }  const clone = {    ...cmd,    pattern: mergePath(path, effectivePattern, true),    includeLastSegment: cmd.pattern === "/" || cmd.includeLastSegment,  };```The key insight was to only apply the basePath transformation when theinner app actually has a basePath (not empty), which preserves backward  compatibility with existing code that doesn't use basePath.  Test Coverage  I added comprehensive test cases covering:1. Inner app with basePath: /v1 + /api basePath + /users route =/v1/api/users2. Main app with basePath + mounted app: /main basePath + /sub mount +/data route = /main/sub/data3. Both main and inner basePath: /main + /services + /api/v2 + /users =/main/services/api/v2/users  Backward Compatibility  The fix maintains full backward compatibility:  - ✅ All existing mountApp() tests pass  - ✅ All existing basePath tests pass  - ✅ New functionality works as expected  Now the three basePath mechanisms work correctly together:  1. Vite base config → Static asset URLs  2. App basePath option → Route matching (now works with mountApp!)  3. External mounting → Framework integrationThe solution correctly handles the scenario you described wherevite.config.ts, main.ts, and external mounting all work togetherseamlessly.

Related#3402

- @fresh/core@2.0.1- @fresh/plugin-vite@1.0.1- @fresh/update@2.0.1- @fresh/init@2.0.7