fix(#1756): deliver user-defined custom fields via HTTP API

[Treygec]

Custom fields configured under Settings → User Fields were never extracted into TaskInfo, so they were absent from all HTTP API responses and could not be written back via the API.

Changes:

• mapTaskFromFrontmatter: new optional userFields param writes each user field present in YAML as a flat top-level property on the returned TaskInfo (e.g. start_date, effort_level), matching the same structure as core fields like due and status.
• mapTaskToFrontmatter: matching optional userFields param reads those top-level properties back and writes them to frontmatter so round-trips are lossless.
• FieldMapper: holds userFields, passes them through both map functions; new updateUserFields() / getUserFields() methods mirror the existing updateMapping() pattern.
• pluginBootstrap: constructs FieldMapper with settings.userFields so user fields are active from startup.
• SettingsLifecycleService: calls updateUserFields() in both saveSettings() and onExternalSettingsChange() so live settings changes take effect without a plugin restart.
• TaskCreationService: copies user field values from taskData into completeTaskData before mapToFrontmatter is called; previously only hardcoded core fields were included so POST /api/tasks silently dropped custom field values.
• TaskService.applyTaskCreationDefaults: changed !result.due and !result.scheduled to === undefined checks so an explicit null from the API is treated as "clear this field" rather than triggering the configured default (e.g. defaulting to today).
• bases/helpers: adds "customProperties" to knownProperties to prevent double-nesting in the Bases integration code path.
• tests: new test suite (16 tests) covering extraction, write-back, round-trips, backward compat, live updateUserFields, and the absence of a customProperties wrapper.