Fix `uri_to_pattern` function incorrectly prepending `/` to all patterns

The uri_to_pattern function in jp_attachment_file_content always prepends a / to patterns, but this changes the semantic meaning of gitignore patterns since leading slashes have specific meaning in gitignore syntax.

Expected Behavior

According to gitignore documentation, patterns with and without leading slashes have different meanings:

• foo matches any file or directory named foo anywhere in the tree
• /foo matches only files or directories named foo at the root level
• foo/bar matches bar inside any directory named foo
• /foo/bar matches bar only inside foo at the root level

The function should preserve the original pattern structure instead of always making patterns absolute.

Actual Behavior

The current uri_to_pattern function always prepends a / to patterns via:

if !path.starts_with('/') {
    path = format!("/{path}");
}

This means that a pattern like *.md becomes /*.md, which only matches markdown files at the root level instead of matching them anywhere in the tree.

Proposed Solution

Modify the uri_to_pattern function to preserve the original pattern semantics. The function should only prepend a / when the URI explicitly indicates a root-level pattern, not as a default behavior.

One approach is to check if the URI path already starts with / and only then treat it as a root-level pattern. For relative patterns, preserve them as-is.

Resources

• https://github.com/dcdpr/jp/blob/main/crates/jp_attachment_file_content/src/lib.rs#L163-L173

Start in crates/jp_attachment_file_content/src/lib.rs around lines 163-173 and inspect the uri_to_pattern function. Compare its handling of relative and root-level gitignore patterns with the documented semantics. Done means patterns such as *.md, /foo, foo/bar, and /foo/bar retain their intended matching scope.