Exposes the Falcon-1024 accounts the previous two commits made reachable.
`POST /v1/wallet/user/` gains one optional `account_type` field; omitting it
produces exactly the ed25519 account it produced before. No other endpoint
takes a new parameter — every route keys off `user_id`, and the service works
out the rest.

Which mount holds a `user_id` is the only record of its account type, so
nothing can drift out of step with Vault. `resolveUserAccount` probes transit
first and falls through to the PQ mount on a 404, which means accounts that
exist today resolve in exactly the request they take now and only PQ accounts
pay for the miss. A non-404 from transit propagates instead of falling through:
"cannot tell" is not the same answer as "not an ed25519 account". `getUserInfo`
is reimplemented on top of the resolver with its signature and response shape
unchanged, so its eight call sites are untouched.

Creation refuses a `user_id` that already exists in the other mount, with a
409. Without that guard the same `user_id` would resolve to two different
addresses depending on probe order — funds to whichever account the resolver
happened to find first. Account type is therefore fixed at creation: the two
schemes derive different addresses, so there is no conversion to offer.

Listing now covers both mounts, and returns real addresses. The internal
`UserInfoDto.public_address` had been carrying a base64 public key that the
wallet layer converted on the way out, which is meaningless for a 1793-byte
Falcon key; both branches now produce the address directly and the conversion
is gone. The transit LIST also stops turning Vault's 404-on-empty-mount into a
500, which becomes reachable for the first time here — a deployment can hold PQ
users and no transit users at all.

`account_type` is additive on the wire but not invisible: it appears in every
user response, so a caller asserting an exact body shape will see it. The
existing `User detail` end-to-end case did, and was updated.

Signing and fees are not part of this change. `signTxAsUser` and
`addSignatureToTxn` are untouched, so no ed25519 transaction can regress; a PQ
account can be created and read but not yet spent from, which needs the `pqsig`
envelope and algod v5.

Unit tests cover the create branch and both 409 directions, transit-first
resolution, the fall-through, the 404 when neither mount holds the user, and
that a non-404 error is not swallowed. The end-to-end suite drives the
endpoints: a falcon1024 create returns the address the plugin derived, reading
the user back resolves it with no hint from the caller, a default create is
still ed25519, both types appear in the listing, and an unknown account_type is
rejected.

Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 22.20.1 to 26.4.1.
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node)

---
updated-dependencies:
- dependency-name: "@types/node"
  dependency-version: 26.4.1
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [eslint](https://github.com/eslint/eslint) from 9.39.5 to 10.9.1.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Commits](https://github.com/eslint/eslint/compare/v9.39.5...v10.9.1)

---
updated-dependencies:
- dependency-name: eslint
  dependency-version: 10.9.1
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [hardhat](https://github.com/NomicFoundation/hardhat/tree/HEAD/packages/hardhat) from 2.29.1 to 3.15.0.
- [Release notes](https://github.com/NomicFoundation/hardhat/releases)
- [Changelog](https://github.com/NomicFoundation/hardhat/blob/main/packages/hardhat/CHANGELOG.md)
- [Commits](https://github.com/NomicFoundation/hardhat/commits/hardhat@3.15.0/packages/hardhat)

---
updated-dependencies:
- dependency-name: hardhat
  dependency-version: 3.15.0
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Wraps the `algorand-pq` secrets engine added in the previous commit so the
service layer can reach Falcon-1024 keys the same way it already reaches
transit ed25519 ones. Pure addition: no existing method, call site or response
shape changes, and nothing yet calls these.

The four wrappers mirror their transit siblings — create (idempotent), read,
sign, list — and share one private request helper, since the plugin does not
imitate transit's quirks and so has none of the per-method special casing the
transit wrappers carry.

Two differences from those siblings are deliberate. Signatures come back raw:
the plugin emits no `vault:v1:` envelope, so nothing may run the transit prefix
split over them, and `decodeVaultSignature` in particular would reject every
Falcon signature on its 64-byte length assertion. And a missing key is an
answer rather than an error: `pqGetKey` returns `undefined` on 404 because the
account-type probe that follows reads a miss as "this user_id is not a PQ
account". `pqSign` keeps throwing on 404, since an unknown key there is a real
failure.

The mount comes from a new `VAULT_PQ_USERS_PATH` in `.env.template`, falling
back to `pawn/pq-users` the way the KV mount falls back to `secret`.
`development-init` seeds `.env` only when the file is absent, so without the
fallback every existing checkout would resolve an undefined mount against a
Vault that has the engine mounted correctly. The path stays a literal in
`development-init.ts` and the e2e suite: the former writes `.env` from the
template and so cannot consume the variable it creates, which is why its
transit paths are literals too.

Unit tests cover response parsing, the mount override and namespace header, the
404-to-`undefined` path, that the signing input is passed through base64
unmodified, and that a raw signature survives with no prefix stripped. Verified
against the running dev stack as well: a key created through these methods reads
back identically, re-creating it is idempotent, signing yields a 1226-byte
buffer, and the user AppRole is denied on sign while the manager succeeds.

Updates the requirements on [vue-router](https://github.com/vuejs/router) to permit the latest version.
- [Release notes](https://github.com/vuejs/router/releases)
- [Commits](https://github.com/vuejs/router/compare/v5.3.0...v5.3.1)

---
updated-dependencies:
- dependency-name: vue-router
  dependency-version: 5.3.1
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>