[4453] use-package 带路径包名改为按 package/style 根目录直查

[priyanshusky0]

Fixes #4453.

What was broken

A user package installed under $TEXMACS_HOME_PATH/packages/ that loads its own
sub-packages with a path-qualified name stopped cascading between 2026_2.6 and
2026_3.2. Given this layout:

$TEXMACS_HOME_PATH/packages/
└── TST-core/
    ├── unicode-core.ts
    └── unicode/
        ├── unicode-figures.ts
        └── unicode-environments.ts

where unicode-core.ts contains:

<use-package|TST-core/unicode/unicode-figures>
<use-package|TST-core/unicode/unicode-environments>

adding only unicode-core to a document silently fails to load the two
sub-packages, and their macros render as raw markup (⟨big-unicode-table|...⟩).
Adding all three packages to the document's own list works, which is what made
the bug confusing. GNU TeXmacs 2.1.5 and 2026_2.6 are both fine.

Root cause

17e6bab45 ([1200], #4331) added a direct-lookup fast path to
edit_env_rep::exec_use_package. When a package name contains / it calls
resolve_dotted_package, which searched exactly two places:

resolve_pack_in (url ("$TEXMACS_PATH/packages"), pi);
resolve_pack_in (url ("$TEXMACS_PATH/plugins") * pi (0, pos) * "packages", pi);

$TEXMACS_HOME_PATH is never consulted. Before [1200], resolution went through
$TEXMACS_STYLE_PATH, which init_env_vars builds with
search_sub_dirs (style_root | package_root) and which therefore contains
$TEXMACS_HOME_PATH/packages and every subdirectory below it.

The design note in devel/1200.md says the change is compatible because "所有
样式文件均为裸包名，无一带 /". That holds for the bundled tree, but not for
user packages, where a slash-qualified name has always been valid.

Why adding packages to the document list still works: those names first pass
through preprocess_style (new_style.cpp:118), which resolves them against
$TEXMACS_STYLE_PATH and rewrites them to absolute paths before
exec (USE_PACKAGE, ...). An absolute path also contains /, so it enters the
same fast path, but url::operator* returns a rooted right operand unchanged
(lolly/System/Classes/url.cpp:645), so it still resolves. A relative name
inside a package body has no such fallback.

The failure is silent: load_string fails and the package is skipped. The
use-package: package not found: line added by [1200] only appears with
-debug-io.

How it is fixed

resolve_dotted_package now takes base_file_name and searches, in order:

1. $TEXMACS_PACKAGE_ROOT — $TEXMACS_HOME_PATH/packages,
   $TEXMACS_PATH/packages, and plugin_path ("packages")
2. $TEXMACS_STYLE_ROOT — the same three for styles
3. the document's own directory, walking up ancestors for local documents, which
   restores the behaviour the non-slash branch still has

This keeps the [1200] optimisation. Both root variables are set by
init_env_vars and hold on the order of 2 + number of plugins entries; they
are not $TEXMACS_STYLE_PATH, which search_sub_dirs expands recursively
into every subdirectory. Measured stat calls to locate one bundled package:

	stat calls
before [1200]	8
[1200] (current main)	1
this patch	3

plugin_path's base is $TEXMACS_HOME_PATH:$TEXMACS_PATH, so it fully covers
the old $TEXMACS_PATH/plugins/<first-segment>/packages rule and additionally
fixes plugin packages installed under the user's home.

resolve_pack_in gained an or-url branch that walks roots one at a time rather
than handing the whole or-url to resolve. This keeps ".stem before .ts" scoped
to a single root, so a user package can override a bundled one, and it stops at
the first hit instead of sweeping every root for .stem first.

Only exec_use_package was ever converted to the fast path — load_style_tree
(new_buffer.cpp:541) still uses the full $TEXMACS_STYLE_PATH and was never
affected.

Testing

New test: tests/Typeset/Env/use_package_resolve_test.cpp. It builds fixtures
under a temporary $TEXMACS_HOME_PATH, uses only the entry package, and asserts
the cascaded macros actually reach the environment via env->provides (...)
rather than merely checking that files exist.

Run with xmake b use_package_resolve_test && xmake r use_package_resolve_test
on macOS arm64, Qt 6.8.3, releasedbg:

Test case	What it covers	main	this PR
nested_user_package	the reported bug: only TST-core/unicode-core added, both sub-packages must cascade	FAIL	PASS
document_relative_package	document in <doc>/sub/, package in <doc>/relative/, found by ancestor walk	FAIL	PASS
home_plugin_package	package under $TEXMACS_HOME_PATH/plugins/<plugin>/packages	FAIL	PASS
style_root_package	slash-qualified name resolving on a style root	FAIL	PASS
package_root_wins_over_style_root	root precedence when the same relative path exists in two roots	FAIL	PASS
bare_package_name_still_works	names without / still use $TEXMACS_STYLE_PATH — guards the untouched branch	PASS	PASS
missing_package_is_silent	an absent package neither crashes nor defines anything	PASS	PASS

main:      Totals: 4 passed, 5 failed, 0 skipped, 0 blacklisted
this PR:   Totals: 9 passed, 0 failed, 0 skipped, 0 blacklisted

The two control cases passing on main matter: they show the test discriminates
this specific bug instead of failing wholesale.

Additionally verified end to end with the three .ts files attached to the
issue, installed in the exact layout reported. Loading only unicode-core:
big-unicode-table, small-unicode-table, unicode-figures-marker, uno-ref
and uex-ref all resolve with this patch, and on main the same check fails
with use-package: package not found: TST-core/unicode-core.

Not verified locally: the full --group=tests sweep (the machine ran out of
disk partway through linking, not a build error) and any Linux/GCC run. CI
covers both.