Fix lib/ folder DLL resolution for InvokeButton/LinkButton and merge per-user extension paths in all-users installs

[Copilot]

Two regressions in the v6 new loader affecting extensions that use custom DLLs and all-users deployments.

Issue #5 — lib/ folder no longer searched for extension DLLs

InvokeButton and LinkButton assembly resolution only searched bin/ subdirectories. Extensions that followed the pre-v6 convention of placing DLLs under lib/ silently failed to load.

• CommandTypeGenerator.ResolveInvokeAssemblyPath(): adds CollectLibraryPaths() alongside the existing CollectBinaryPaths() call
• LinkButtonBuilder.ResolveAssemblyPath(): same change for LinkButton target assembly resolution

// Before — only bin/ was searched
searchPaths.AddRange(extension.CollectBinaryPaths(component));

// After — lib/ is also searched for backward compatibility
searchPaths.AddRange(extension.CollectBinaryPaths(component));
foreach (var libPath in extension.CollectLibraryPaths(component))
    if (!searchPaths.Contains(libPath))
        searchPaths.Add(libPath);

Issue #2 — Per-user extension search paths ignored in all-users installs

When pyRevit is installed machine-wide, ExtensionParser.GetExtensionRoots() read userextensions exclusively from the ProgramData config. Paths written to the per-user AppData config (by the Settings UI or a non-admin CLI invocation) were never discovered by the C# loader.

• ExtensionParser.GetExtensionRoots(): when IsAllUsersInstall() is true and a separate per-user config exists at %AppData%\pyRevit, its userextensions entries are merged into the roots list using a HashSet<string> for O(1) case-insensitive deduplication.

• Fixes [Bug]: pyRevit_6.4.0.26100 Bugs [CLI-based Search Paths, DLLs lib vs bin folder] #3312

[devloai]

Unable to trigger custom agent "Code Reviewer". You have run out of credits 😔
Please upgrade your plan or buy additional credits from the subscription page.

[romangolev]

@jmcouffin I'm getting back from vacation tomorrow and will take a look on that and others PRs this weekend

[romangolev]

Two configuration-scope issues need attention before this fix fully addresses all-users installations.

[romangolev]

[P1] Respect the read-only machine-config policy before merging user paths. GetActiveConfig() deliberately treats a ProgramData config with the ReadOnly attribute as an admin lock, but this condition checks only the installation scope. It therefore still loads extensions from a user-writable AppData config, bypassing that policy. Please skip this merge when the active config is read-only.

[romangolev]

[P2] Merge machine paths when the active config has fallen back to the per-user config. In a normal non-elevated all-users session, GetActiveConfig() uses AppData whenever ProgramData is not writable. perUserConfigPath then equals activeConfigPath, so this block is skipped and machine-scope userextensions added after the initial seed are never discovered—the admin-scope case from #3312 remains. Consider merging both configs based on ActiveConfigInfo while still honoring the read-only lock.