Add HTTP method matching to resource rules

[Blacks-Army]

Resolves #1408. Supersedes #2131, following the three points @oschwartz10612 asked for there: no new columns, verifySession kept small, rebased onto dev.

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

AI Disclosure

Claude Code (Opus) helped me with this one, including the implementation. I set the design constraints from your review of #2131, went through every hunk myself and verified the result before opening this.

Description

A rule with match METHOD carries a comma-separated list of HTTP methods in its value, e.g. "POST,PUT", and applies when the request method is in that list. That makes it possible to leave GET public while sending POST and PUT to auth, which rules could not express before because both share the same path.

No new columns: the methods live in the existing rule value, so there is no migration and every existing rule keeps working unchanged.

verifySession: one else if at the end of the existing chain in checkRules plus one short helper next to the other isIpIn* functions. Rule processing is not split into a new file and nothing else in the hot path is restructured.

METHOD is added to RESOURCE_RULE_MATCH_TYPES in server/lib/validators.ts, so every route that validates rules picks it up from there, OpenAPI enum included. Badger already sends method in the verify-session payload; the field was simply unused until now.

The UI offers the ten registered methods: the eight from RFC 9110 plus PATCH (RFC 5789) and QUERY (RFC 10008). Blueprints and the API accept any method token, so extension methods such as the WebDAV verbs can be targeted too, and the UI preserves them when a rule set that way is edited later. Matching is case-insensitive on both sides.

pangolin-node carries its own copy of checkRules and needs the same change. I will open that PR next and link it here.

How to test?

1. On an HTTP resource, enable rules and add: priority 1 ACCEPT / METHOD / GET,HEAD, priority 2 PASS / METHOD / POST,PUT.
2. curl the resource with -X GET and confirm it is served without auth.
3. curl -X POST the same URL and confirm it is sent to auth.
4. Confirm an existing PATH or CIDR rule on another resource still behaves as before.

Blueprint variant:

rules:
  - action: pass
    match: method
    value: POST,PUT

npx tsc --noEmit is clean and npx tsx server/lib/validators.test.ts passes.

[Blacks-Army]

@miloschwartz npm ci fails on dev in both pangolin and pangolin-node, so every PR against dev is red regardless of its content.

Your commit "switch to lru in memory cache and dont cache failed sessions" (c792622 here, 49292ea in pangolin-node, both 2026-09-10) moved package.json from node-cache to lru-cache@11.5.2 without regenerating package-lock.json.

On a clean dev checkout:

npm error Invalid: lock file's lru-cache@11.3.6 does not satisfy lru-cache@11.5.2

npm install --package-lock-only fixes it. I left it out of my PR, since it is
unrelated and would conflict as soon as you fix dev.

[Blacks-Army]

@oschwartz10612 Rebased onto the latest dev. All checks are green except
ESLint, which fails on a clean dev checkout too (typescript-eslint@8.70.0
hard-errors on TypeScript 7), so it's unrelated to this PR.

Also Rebased this PR #3705

[oschwartz10612]

Thanks!