feat: add current lorebook entries plugin api

[yaa19212-droid]

PR Checklist

• Required Checks
  • Have you added type definitions?
  • Have you tested your changes?
  • Have you checked that it won't break any existing features?
• If your PR uses models¹, check the following:
  • Have you checked if it works normally in all models?
  • Have you checked if it works normally in all web, local, and node-hosted versions? If it doesn't, have you blocked it in those versions?
• If your PR is highly AI generated², check the following:
  • Have you understood what the code does?
  • Have you cleaned up any unnecessary or redundant code?
  • Is it not a huge change?
    • We currently do not accept highly AI generated PRs that are large changes.

Summary

Adds risuai.getCurrentLorebookEntries() to the v3 plugin API.

The new API returns raw lorebook entries from these current sources:

• current character or group globalLore
• current chat localLore
• lorebooks from currently active modules

It does not apply lorebook activation, recursive scanning, or token budget filtering.

Related Issues

None.

Changes

• Added getCurrentLorebookEntries() to RisuaiPluginAPI.
• Implemented getCurrentLorebookEntries() in the v3 plugin API.
• Reused getModuleLorebooks() for currently active module lorebooks instead of reimplementing active module resolution in the plugin API layer.

RisuAI already combines the same source categories when building lorebook prompts:

const characterLore = char.globalLore ?? []
const chatLore = char.chats[page].localLore ?? []
const moduleLorebook = getModuleLorebooks()

This PR exposes that raw source collection to plugins without exposing whole character, chat, or module objects.

Impact

This is an additive v3 plugin API. Existing APIs and lorebook activation behavior are unchanged.

The API is intended for plugins that need to search lorebook entries from the current character, chat, and active modules. Existing workarounds can require snapshotting larger parent objects:

• getCharacter() for character or group globalLore
• getChatFromIndex() for chat localLore
• getDatabase(['modules']) plus plugin-side active module resolution for
  module lorebooks

Large character cards or modules may contain unrelated fields such as asset reference arrays, trigger/script data, HTML/CSS, or long chat data. Module asset binaries are stored separately, but module objects can still include large asset metadata/reference arrays with names, file names, and SHA-256-based asset paths.

Behavior notes:

• Returns raw entries before activation matching.
• Includes entries regardless of whether they would become active in the final prompt.
• Includes group globalLore, matching the source collection used by loadLoreBookV3Prompt().
• Returns a snapshot, so plugin-side mutations do not modify host state.
• Does not expose inactive modules as module objects.
• Does not return module assets.

Additional Notes

Verification:

• Ran pnpm run check.
• svelte-check reported 0 errors and 0 warnings.

Local benchmark context:

I tested the current workaround with a v3 benchmark plugin against a local RisuAI database containing large modules. In that environment:

• getDatabase(['enabledModules']) returned in about 1-2 ms with a payload of a few hundred bytes.
• getDatabase(['modules']) took about 300 ms and returned about 4.20 MB.
• getCharacter() took about 1 second in the tested character contexts.
• The combined current character/chat/active-module lorebook entries were roughly 100-200 KB in those tests.

The exact numbers depend on user data, but the results show that current workarounds can copy large parent objects and asset reference arrays that are unrelated to lorebook lookup.

Footnotes

1. Modifies the behavior of prompting, requesting, or handling responses from AI models. ↩

2. Over 80% of the code is AI generated. ↩

[cubicj]

Verified the plugin API path. It returns a snapshot of the current raw lorebook sources without touching DB write APIs.

Check, tests, and build pass locally.

Approving — thanks for the contribution!