(sidebar): key remote project hiding by alias, not path alone

[devsuitup]

Hiding a project that lives on a remote SSH host had two defects. Neither
changes the behaviour of hiding a local project.

The cleanup deleted the wrong folder

The handler derived the cache key from the path alone:

const folder = encodeProjectPath(projectPath);
deleteCachedFolder(folder);
deleteSearchFolder(folder);

For a remote group that yields -tmp-x where the real key is
planificator::-tmp-x. Nothing matched, silently: the hidden project kept its
rows in session_cache and its entries in the search index, so its sessions
still came back in search results after being hidden.

The renderer now passes the group's folder key, which is used verbatim when
present. Without it the previous behaviour stands, so every other caller is
unaffected.

The hidden identity did not match the group identity

Sidebar groups are keyed on alias + projectPath — two hosts can hold the same
absolute path, and so can this machine. The hidden list held bare paths, so
hiding a remote /srv/x also hid a local /srv/x.

A hidden entry is now either a bare path, which keeps its legacy meaning of
hiding that path everywhere, or <alias>::<projectPath>, which hides it on
that host only. Existing entries are left as they are — they keep working.
One helper, isProjectHidden, carries the test for all three filter sites.

Verification

Mutation-pinned in both directions:

• Reverting session-cache.js alone turns red exactly the two tests asserting
  that a host-qualified hide leaves the identically-named local group alone.
  The legacy bare-path test stays green, which is the point: that behaviour is
  unchanged.
• Reverting the four wiring files turns red all four tests covering the folder
  key's path from the sidebar to the handler.

task check: 1153 passed, 0 failed, 8 pre-existing skips, lint 0 errors.