chore(release): 3.2.7

[Falcion]

PRs: update OBSIDIAN API, add "forced" modes and fix settings

Before writing anything about your changes in this PR, checklist this items:

• Agreed with current version of code of conduct.
• Read and followed current version of “issue policy”.
• Read and followed current version of “commit convention”.

By agreeding and following this project's documentation, you are reminded that your's commit and styling of changes must follow this project's documentation, in case of “de-followization”, there are two ways before you make sure to publishing your PR:

1. In case of “de-followization” of commit's styling convention, you can amend them (change their message and description signatures):

git commit --amend -m "MESSAGE" -m "DESCRIPTION"

For amending old commit, see the stackoverflow question¹, more about changing commits in official docs for github:
https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message/

2. In case of “de-followization” of coding, documentation and etc. files, you can just refactor everything you need by following styling guidelines of project.

Changes with that PR

Please, write below every changes you made:

1. updated "obsidian" (Obsidian's API) to last version (1.10*);
2. updated "obsidian-typings" (typing of Obsidian's API) to last version (2.44*);
3. fix issue, where "use default extensions" feature lagged and displayed input incorrectly (fix of #158);
4. make "silence errors" feature true by default;

Process of testing for that PR

• Was testing process initiated via this PR?
  answer (y/n): (n);
• If testing was done, type below the procedures you make:
  ...

Additional context for that PR

Closes #160
Closes #159
Closes #158

Footnotes

1. https://stackoverflow.com/questions/17338792/amending-old-commit/ ↩

In general, a safe deep-assignment function that receives untrusted paths must either (a) block dangerous property names such as __proto__, constructor, and prototype, or (b) ensure that it never operates on objects that could end up in any prototype chain. Since we cannot change how setDeep is used, the robust fix is to add explicit checks that prevent traversing or creating these dangerous properties anywhere along the path.

The best targeted fix here is: when iterating parts in setDeep, skip or reject any segment that equals "__proto__", "constructor", or "prototype". If such a key is encountered either in the loop (for intermediates) or for the final segment, we should stop and return obj without creating or modifying anything. This preserves all existing behavior for legitimate keys while preventing pollution. Concretely:

• After computing parts = path.split('.'), we can either (1) scan parts once and early-return if any forbidden key is present, or (2) check each segment just before using it (p inside the loop and parts[parts.length - 1] for the final write). To keep the change minimal and localized, we can add a small helper isUnsafeKey in this file and use it where keys are read.
• All changes occur in source/settings/utils/functions/deep.ts, only inside the shown code. No behavior changes for safe keys; dangerous keys now cause setDeep to do nothing.

In general, to fix regex injection from command-line or other untrusted input, avoid passing the raw string directly to new RegExp and either (a) escape regex metacharacters so the string is treated as a literal, or (b) strictly validate or whitelist permitted patterns. In this case, the most conservative and backwards-compatible approach is: keep accepting RegExp objects from opts.filter (for intentional complex patterns), but treat the CLI string --worker-filter as a literal substring to match in filenames, escaping regex metacharacters before constructing the RegExp.

Concretely for build/plugin-workers.mjs, we should change the logic on lines 21–23 so that:

• We distinguish whether the filter originates from opts.filter or from the CLI.
• If it is a string from the CLI, we escape regex metacharacters before constructing the RegExp.
• If it is already a RegExp, or a string passed via opts.filter (which is programmatic and presumably trusted), we keep the existing behavior.

Since we are allowed to add well-known dependencies, we can import escapeRegExp from lodash (or lodash.escaperegexp), but that’s not strictly required; we can also implement a simple escape function locally. To minimize changes and dependencies, we can define a small escapeRegExp helper in this file and use it only for CLI-derived string filters, leaving the rest of the functionality intact.

Steps:

1. In build/plugin-workers.mjs, add a local escapeRegExp function near the top of the file.
2. Replace the rawFilter / filter construction so that:
   • It first prefers opts.filter (which may be a RegExp or string).
   • If no opts.filter is given and cli["worker-filter"] is present:
     • If it’s a string, escape it and build new RegExp(escapedString).
   • Otherwise fall back to DEFAULT_FILTER.
3. Ensure that at the end we always have filter as a RegExp (as before) so downstream code does not change behavior except for treating CLI strings as literals.

In general, when constructing JavaScript source code that embeds stringified data, you should apply an additional escaping step to the JSON.stringify result to neutralize characters that can break out of <script> tags or otherwise alter the surrounding JavaScript/HTML context. This is particularly important for <, >, /, backslashes, control characters, and Unicode line/paragraph separators.

The single best fix here is to introduce a small helper function within build/plugin-workers.mjs that escapes unsafe characters in a string (following the pattern from the background example) and then wrap the existing JSON.stringify(args.path) call with this helper. This preserves existing functionality—the generated JavaScript still uses new URL(<string>, import.meta.url)—while ensuring that any unexpected characters in args.path cannot produce malformed or unsafe generated code.

Concretely:

• Add a const charMap and function escapeUnsafeChars(str) near the top of build/plugin-workers.mjs (after the imports or after the JSDoc typedef, anywhere before use).
• Change line 28 so that it reads escapeUnsafeChars(JSON.stringify(args.path)) instead of just JSON.stringify(args.path).
• No new external imports are needed; the helper uses only built-in JavaScript features.