Fix the build, the 404 consent URL, and put AI/ML API first

[Lookoff-AIMLAPI]

Summary

Three commits, deliberately kept separate so the first two can go upstream later and the third cannot.

1. main does not compile

PR #2 deleted crates/goose/src/providers/aimlapi.rs when the hand-written provider was replaced by the declarative definition, but left both references behind:

crates/goose/src/providers/mod.rs   pub mod aimlapi;
crates/goose/src/providers/init.rs  aimlapi::AimlapiProvider
                                    registry.register::<AimlapiProvider>(false)

Nothing under crates/goose/src/providers/ resolves those — no aimlapi.rs, no aimlapi/ directory — so the crate fails to build on main today. This removes the leftovers.

The provider docs row also advertised AIMLAPI_HOST; the declarative definition has a fixed base_url and reads only AIMLAPI_API_KEY, so that parameter never did anything.

2. The consent URL 404'd, and the tests were never running

verificationBaseUrl is handed to the server, which returns it with /agent/authorize appended. The web app is served under an /app/ base path, so the default produced:

URL
https://aimlapi.com/agent/authorize	404 — what we were sending users to
https://aimlapi.com/app/agent/authorize	200 — where the page actually is

Every sign-in died on its first step. Fixed on this side rather than server-side, to keep the change off the shared default other clients already depend on.

Separately, the test module in server.rs had never compiled: CallbackQuery gained a state field when state verification went in and the test's initializer was not updated, so cargo test skipped the module entirely and the two HTML-escaping tests silently never ran.

Adds a tests module mirroring signup_openrouter:

• the challenge really is the S256 hash of the verifier
• challenge and state are url-safe and unpadded
• separate flows share no verifier, state or challenge
• the partner id matches the shape the gateway attributes (part_<alnum>)
• the API host and the consent host stay distinct
• the consent base keeps its /app, so a future tidy-up of that URL fails a test instead of a user

3. Sign-in menu placement — fork only, do not take upstream

AI/ML API moves to the top of the setup picker with the same (Recommended) label. OpenRouter's own label is untouched and no other entry changes.

This is a deliberate choice for our build. The menu is a hand-ordered list in someone else's repository and nothing in the provider schema makes "recommended" a claimable flag. The manual provider list is unaffected — it sorts by display_name, where AI/ML API already lands first on its own merit, 1st of 46.

Verification

• cargo build -p goose-cli --no-default-features --features "code-mode,aws-providers,telemetry,nostr,otel,rustls-tls,system-keyring,update" — succeeds. (The default local-inference feature needs libclang for bindgen, which is why this tree previously would not build locally; it is unrelated to these changes.)
• cargo test -p goose --lib signup_aimlapi — 8 passed, including the two in server.rs that compile here for the first time.
• cargo fmt --check — clean on both edited crates.
• Live, end to end against production: goose configure → AI/ML API sign-in → browser consent → loopback redirect → code+verifier exchange → key stored. Then, with no environment variables set at all, goose run answers on aimlapi anthropic/claude-sonnet-5. The declarative provider was also verified separately on openai/gpt-5-5.