conan upload collects no artifacts when the reference has a user (regression since 2.97.0)

[gravityXX]

Describe the bug

jf conan upload --build-name --build-number silently collects no artifacts when
the package reference carries a Conan user, for example pkg/1.0@myuser. The
command logs Collected 0 Conan artifacts and exits 0, the published build info
has an empty artifact list, and a later jf rt build-promote copies no files
while still returning success. Nothing in the output indicates a failure.

Current behavior

buildArtifactPathsFromJSON in artifactory/commands/conan/upload.go builds the
lookup paths with the user segment hardcoded to the _ placeholder:

recipePath := fmt.Sprintf("_/%s/_/%s/export", pkgRef, recipeRev)
pkgPath    := fmt.Sprintf("_/%s/_/%s/package/%s/%s", pkgRef, recipeRev, pkgID, pkgRev)

pkgRef is Conan's own rendering of the reference, so for a package created with
--user=myuser it already is pkg/1.0@myuser. The resulting lookup is

_/pkg/1.0@myuser/_/<rrev>/export

while Artifactory stores the files under <user>/<name>/<version>/<channel>/<rrev>:

myuser/pkg/1.0/_/<rrev>/export

The search matches nothing. An empty result is not an error, and the property
tagging and module update are both behind if len(artifacts) > 0, so the command
succeeds with nothing collected.

Expected behavior

The artifacts of a reference with a user are collected, tagged with the build
properties and recorded in the build info, exactly as for a reference without one.

Reproduction

conan create . --name=pkg --version=1.0 --user=myuser
jf conan upload "pkg/1.0@myuser" --remote=<repo> \
  --build-name=demo --build-number=1 --confirm
jf rt build-publish demo 1
jf rt curl -XGET /api/build/demo/1 \
  | jq '[.buildInfo.modules[].artifacts] | flatten | length'

Result: 0. Dropping @myuser from the reference gives the expected count.

Regression range

Working before 2.97.0. The path handling was fixed in #382 and reintroduced in
#392, which moved to the JSON upload format and removed the @myuser/stable test
case added by #382. Still present on main today and in v2.117.0.

Suggested fix

Split the user and the channel out of the reference and place them in their own
path segments, defaulting each to _ when absent, rather than rendering the
reference into a single segment. Note that #404 addresses a related parsing
problem but requires both a user and a channel to be present, so it would not
cover pkg/1.0@myuser.

Why it matters

The failure is silent in a release path. A promotion built on such a build info
reports success and copies nothing, so a package can appear released while the
target repository stays empty.