fix: sanitize LoRA paths and enable dynamic loading

[MateusGPe]

• Implement sanitize_lora_path in SDGenerationParams to prevent directory traversal attacks via LoRA tags in prompts.
• Restrict LoRA paths to be relative and strictly within the configured LoRA directory (no subdirectories allowed, optional? drawback: users cannot organize their LoRAs into subfolders).
• Update server example to pass lora_model_dir to process_and_check, enabling LoRA extraction from prompts.
• Force LORA_APPLY_AT_RUNTIME in the server to allow applying LoRAs dynamically per request without reloading the model and avoiding weight accumulation.

[MateusGPe]

Is this block optional or required? It has a clear disadvantage: users cannot organize their LoRA files into subfolders.

        // 3. The file must be directly in the lora directory, not in a subdirectory.
        if (relative_path.has_parent_path() && !relative_path.parent_path().empty()) {
            LOG_WARN("lora path in subdirectories is not allowed: %s", raw_path_str.c_str());
            return false;
        }

Proposals:

• Remove it;
• Use a flag or macro to enable/disable;
• Maintain as is.

[wbruna]

Why is this needed at this point?

[MateusGPe]

I apologize, I realized it's redundant, the code following this block does that:

            const std::string key = final_path.lexically_normal().string();

[wbruna]

* Force `LORA_APPLY_AT_RUNTIME` in the server to allow applying LoRAs dynamically per request without reloading the model and avoiding weight accumulation.

Since we have a parameter controlling that, the server should follow it. But I think it'd be OK to have its value default to at_runtime for the server.

[MateusGPe]

The problems that were identified have been resolved, I believe.

[MateusGPe]

I apologize, I realized it's redundant, the code following this block does that:

            const std::string key = final_path.lexically_normal().string();