chore: merge upstream/dev into the embed fork

.env.example

@@ -9,11 +9,6 @@ PUBLIC_COMMIT_HASH=""
 
 ADDRESS_HEADER="CF-Connecting-IP"
 
-# Sentry.io
-PUBLIC_SENTRY_DSN=""
-PUBLIC_SENTRY_HOST=""
-PUBLIC_SENTRY_PROJECT_ID=""
-
 # GO API
 PUBLIC_API_URL="http://localhost:8080/api/"
 PUBLIC_SERVER_API_URL="http://localhost:8080/api/" # If you're using docker, set this to the name of the backend container, e.g. http://skycrypt-backend-1:8080/api/
@@ -39,16 +34,36 @@ MC_ID_CLIENT_SECRET=""
 # https://www.patreon.com/portal/registration/register-clients
 PATREON_CLIENT_ID=""
 PATREON_CLIENT_SECRET=""
+# Numeric campaign ID from the Patreon campaign URL/API response
+PATREON_CAMPAIGN_ID=""
+PATREON_CREATOR_ACCESS_TOKEN=""
+PATREON_CREATOR_REFRESH_TOKEN=""
+PUBLIC_PATREON_COLORED_HEART_CENTS="500"
+PUBLIC_PATREON_ANY_EMOJI_CENTS="6000"
+
+# Newsroom uploads (Cloudflare R2)
+# Create an R2 API token with Object Read & Write on the bucket. The bucket needs a CORS rule allowing PUT with the
+# content-type header from your ORIGIN, because browsers upload straight to R2.
+R2_ACCOUNT_ID=""
+R2_ACCESS_KEY_ID=""
+R2_SECRET_ACCESS_KEY=""
+R2_BUCKET=""
+PUBLIC_MEDIA_URL="" # Public URL of the bucket, e.g. an R2 custom domain like https://media.shiiyu.moe
 
-# Payload CMS
-PUBLIC_CMS_URL="https://cms.shiiyu.moe"
-SERVER_CMS_API_URL="https://cms.shiiyu.moe" # If you're using docker, set this to the name of the CMS container
-CMS_API_TOKEN="" # Users API Key generated in CMS admin (Users → API Key tab)
-CMS_PREVIEW_TOKEN="" # Must match CMS_PREVIEW_TOKEN in SkyCrypt-CMS .env
+# Logging (evlog) - leave empty to log to stdout only
+# Base URL of the HyperDX OTLP HTTP intake, e.g. http://skycrypt-hyperdx:4318 (on the Dokploy network)
+HYPERDX_OTLP_ENDPOINT=""
+# Ingestion key from HyperDX: Team Settings -> API Keys
+HYPERDX_API_KEY=""
 
 # Umami Analytics
 PUBLIC_UMAMI_WEBSITE_ID=""
 PUBLIC_UMAMI_SCRIPT_URL=""
 PUBLIC_UMAMI_RECORDER_URL=""
 PUBLIC_UMAMI_HOST_URL=""
-PUBLIC_UMAMI_ENABLE_HEATMAPS="false"
+PUBLIC_UMAMI_ENABLE_HEATMAPS="false"
+
+# Cloudflare Turnstile
+# https://developers.cloudflare.com/turnstile/troubleshooting/testing/#test-sitekeys
+PUBLIC_TURNSTILE_SITE_KEY="1x00000000000000000000AA"
+TURNSTILE_SECRET_KEY="1x0000000000000000000000000000000AA"

.github/actions/pnpm-install/action.yml

@@ -39,10 +39,9 @@ runs:
       uses: actions/checkout@v7
 
     - name: Setup pnpm
-      uses: pnpm/action-setup@v6
+      uses: pnpm/setup@v3
       with:
-        version: 11.11.0
-        run_install: false
+        version: 12
 
     - name: Setup Node.js
       uses: actions/setup-node@v7

.github/agents/svelte-file-editor.agent.md

@@ -0,0 +1,67 @@
+---
+name: svelte-file-editor
+description: Specialized Svelte 5 code editor. MUST BE USED PROACTIVELY when creating, editing, or reviewing any .svelte file or .svelte.ts/.svelte.js module and MUST use the tools from the MCP server or the `svelte-file-editor` skill if they are available. Fetches relevant documentation and validates code using the Svelte MCP server tools.
+---
+
+You are a Svelte 5 expert responsible for writing, editing, and validating Svelte components and modules. You have access to the Svelte MCP server which provides documentation and code analysis tools. Always use the tools from the Svelte MCP server to fetch documentation with `get_documentation` and validate the code with `svelte_autofixer`. If the autofixer returns any issue or suggestions try to solve them.
+
+If the MCP tools are not available you can use the `svelte-code-writer` skill to learn how to use the `@sveltejs/mcp` cli to access the same tools.
+
+If the skill is not available you can run `npx @sveltejs/mcp@latest -y --help` to learn how to use it.
+
+## Available MCP tools
+
+### 1. list-sections
+
+Lists all available Svelte 5 and SvelteKit documentation sections with titles and paths. Use this first to discover what documentation is available.
+
+### 2. get-documentation
+
+Retrieves full documentation for specified sections. Accepts a single section name or an array of section names. Use after `list-sections` to fetch relevant docs for the task at hand.
+
+**Example sections:** `$state`, `$derived`, `$effect`, `$props`, `$bindable`, `snippets`, `routing`, `load functions`
+
+### 3. svelte-autofixer
+
+Analyzes Svelte code and returns suggestions to fix issues. Pass the component code directly to this tool. It will detect common mistakes like:
+
+- Using `$effect` instead of `$derived` for computations
+- Missing cleanup in effects
+- Svelte 4 syntax (`on:click`, `export let`, `<slot>`)
+- Missing keys in `{#each}` blocks
+- And more
+
+## Workflow
+
+When invoked to work on a Svelte file:
+
+### 1. Gather context (if needed)
+
+If you're uncertain about Svelte 5 syntax or patterns, use the MCP tools:
+
+1. Call `list-sections` to see available documentation
+2. Call `get-documentation` with relevant section names
+
+### 2. Read the target file
+
+Read the file to understand the current implementation.
+
+### 3. Make changes
+
+Apply edits following Svelte 5 best practices:
+
+### 4. Validate changes
+
+After editing, ALWAYS call `svelte-autofixer` with the updated code to check for issues.
+
+### 5. Fix any issues
+
+If the autofixer reports problems, fix them and re-validate until no issues remain.
+
+## Output format
+
+After completing your work, provide:
+
+1. Summary of changes made
+2. Any issues found and fixed by the autofixer
+3. Recommendations for further improvements (if any)

.github/skills/svelte-code-writer/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: svelte-code-writer
+description: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating, editing or analyzing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.
+---
+
+## CLI tools
+
+You have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:
+
+### List documentation sections
+
+```bash
+npx @sveltejs/mcp list-sections
+```
+
+Lists all available Svelte 5 and SvelteKit documentation sections with titles and paths.
+
+### Get documentation
+
+```bash
+npx @sveltejs/mcp get-documentation "<section1>,<section2>,..."
+```
+
+Retrieves full documentation for specified sections. Use after `list-sections` to fetch relevant docs.
+
+**Example:**
+
+```bash
+npx @sveltejs/mcp get-documentation "$state,$derived,$effect"
+```
+
+### Svelte autofixer
+
+```bash
+npx @sveltejs/mcp svelte-autofixer "<code_or_path>" [options]
+```
+
+Analyzes Svelte code and suggests fixes for common issues.
+
+**Options:**
+
+- `--async` - Enable async Svelte mode (default: false)
+- `--svelte-version` - Target version: 4 or 5 (default: 5)
+
+**Examples:**
+
+```bash
+# Analyze inline code (escape $ as \$)
+npx @sveltejs/mcp svelte-autofixer '<script>let count = \$state(0);</script>'
+
+# Analyze a file
+npx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte
+
+# Target Svelte 4
+npx @sveltejs/mcp svelte-autofixer ./Component.svelte --svelte-version 4
+```
+
+**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\$` to prevent shell variable substitution.
+
+## Workflow
+
+1. **Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics
+2. **Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues
+3. **Always validate** - Run `svelte-autofixer` before finalizing any Svelte component

.github/skills/svelte-core-bestpractices/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: svelte-core-bestpractices
+description: Guidance on writing fast, robust, modern Svelte code. Load this skill whenever in a Svelte project and asked to write/edit or analyze a Svelte component or module. Covers reactivity, event handling, styling, integration with libraries and more.
+---
+
+## `$state`
+
+Only use the `$state` rune for variables that should be _reactive_ — in other words, variables that cause an `$effect`, `$derived` or template expression to update. Everything else can be a normal variable.
+
+Objects and arrays (`$state({...})` or `$state([...])`) are made deeply reactive, meaning mutation will trigger updates. This has a trade-off: in exchange for fine-grained reactivity, the objects must be proxied, which has performance overhead. In cases where you're dealing with large objects that are only ever reassigned (rather than mutated), use `$state.raw` instead. This is often the case with API responses, for example.
+
+## `$derived`
+
+To compute something from state, use `$derived` rather than `$effect`:
+
+```js
+// do this
+let square = $derived(num * num);
+
+// don't do this
+let square;
+
+$effect(() => {
+	square = num * num;
+});
+```
+
+> [!NOTE] `$derived` is given an expression, _not_ a function. If you need to use a function (because the expression is complex, for example) use `$derived.by`.
+
+Deriveds are writable — you can assign to them, just like `$state`, except that they will re-evaluate when their expression changes.
+
+If the derived expression is an object or array, it will be returned as-is — it is _not_ made deeply reactive. You can, however, use `$state` inside `$derived.by` in the rare cases that you need this.
+
+## `$effect`
+
+Effects are an escape hatch and should mostly be avoided. In particular, avoid updating state inside effects.
+
+- If you need to sync state to an external library such as D3, it is often neater to use [`{@attach ...}`](references/attach.md)
+- If you need to run some code in response to user interaction, put the code directly in an event handler or use a [function binding](references/bind.md) as appropriate
+- If you need to log values for debugging purposes, use [`$inspect`](references/inspect.md)
+- If you need to observe something external to Svelte, use [`createSubscriber`](references/svelte-reactivity.md)
+
+Never wrap the contents of an effect in `if (browser) {...}` or similar — effects do not run on the server.
+
+## `$props`
+
+Treat props as though they will change. For example, values that depend on props should usually use `$derived`:
+
+```js
+// @errors: 2451
+let { type } = $props();
+
+// do this
+let color = $derived(type === 'danger' ? 'red' : 'green');
+
+// don't do this — `color` will not update if `type` changes
+let color = type === 'danger' ? 'red' : 'green';
+```
+
+## `$inspect.trace`
+
+`$inspect.trace` is a debugging tool for reactivity. If something is not updating properly or running more than it should you can add `$inspect.trace(label)` as the first line of an `$effect` or `$derived.by` (or any function they call) to trace their dependencies and discover which one triggered an update.
+
+## Events
+
+Any element attribute starting with `on` is treated as an event listener:
+
+```svelte
+<button onclick={() => {...}}>click me</button>
+
+<!-- attribute shorthand also works -->
+<button {onclick}>...</button>
+
+<!-- so do spread attributes -->
+<button {...props}>...</button>
+```
+
+If you need to attach listeners to `window` or `document` you can use `<svelte:window>` and `<svelte:document>`:
+
+```svelte
+<svelte:window onkeydown={...} />
+<svelte:document onvisibilitychange={...} />
+```
+
+Avoid using `onMount` or `$effect` for this.
+
+## Snippets
+
+[Snippets](references/snippet.md) are a way to define reusable chunks of markup that can be instantiated with the [`{@render ...}`](references/render.md) tag, or passed to components as props. They must be declared within the template.
+
+```svelte
+{#snippet greeting(name)}
+	<p>hello {name}!</p>
+{/snippet}
+
+{@render greeting('world')}
+```
+
+> [!NOTE] Snippets declared at the top level of a component (i.e. not inside elements or blocks) can be referenced inside `<script>`. A snippet that doesn't reference component state is also available in a `<script module>`, in which case it can be exported for use by other components.
+
+## Each blocks
+
+Prefer to use [keyed each blocks](references/each.md) — this improves performance by allowing Svelte to surgically insert or remove items rather than updating the DOM belonging to existing items.
+
+> [!NOTE] The key _must_ uniquely identify the object. Do not use the index as a key.
+
+Avoid destructuring if you need to mutate the item (with something like `bind:value={item.count}`, for example).
+
+## Using JavaScript variables in CSS
+
+If you have a JS variable that you want to use inside CSS you can set a CSS custom property with the `style:` directive.
+
+```svelte
+<div style:--columns={columns}>...</div>
+```
+
+You can then reference `var(--columns)` inside the component's `<style>`.
+
+## Styling child components
+
+The CSS in a component's `<style>` is scoped to that component. If a parent component needs to control the child's styles, the preferred way is to use CSS custom properties:
+
+```svelte
+<!-- Parent.svelte -->
+<Child --color="red" />
+
+<!-- Child.svelte -->
+<h1>Hello</h1>
+
+<style>
+	h1 {
+		color: var(--color);
+	}
+</style>
+```
+
+If this is impossible (for example, the child component comes from a library) you can use `:global` to override styles:
+
+```svelte
+<div>
+	<Child />
+</div>
+
+<style>
+	div :global {
+		h1 {
+			color: red;
+		}
+	}
+</style>
+```
+
+## Context
+
+Consider using context instead of declaring state in a shared module. This will scope the state to the part of the app that needs it, and eliminate the possibility of it leaking between users when server-side rendering.
+
+Use `createContext` rather than `setContext` and `getContext`, as it provides type safety.
+
+## Async Svelte
+
+If using version 5.36 or higher, you can use [await expressions](references/await-expressions.md) and [hydratable](references/hydratable.md) to use promises directly inside components. Note that these require the `experimental.async` option to be enabled in `svelte.config.js` as they are not yet considered fully stable.
+
+## Avoid legacy features
+
+Always use runes mode for new code, and avoid features that have more modern replacements:
+
+- use `$state` instead of implicit reactivity (e.g. `let count = 0; count += 1`)
+- use `$derived` and `$effect` instead of `$:` assignments and statements (but only use effects when there is no better solution)
+- use `$props` instead of `export let`, `$$props` and `$$restProps`
+- use `onclick={...}` instead of `on:click={...}`
+- use `{#snippet ...}` and `{@render ...}` instead of `<slot>` and `$$slots` and `<svelte:fragment>`
+- use `<DynamicComponent>` instead of `<svelte:component this={DynamicComponent}>`
+- use `import Self from './ThisComponent.svelte'` and `<Self>` instead of `<svelte:self>`
+- use classes with `$state` fields to share reactivity between components, instead of using stores
+- use `{@attach ...}` instead of `use:action`
+- use clsx-style arrays and objects in `class` attributes, instead of the `class:` directive