fix(portfolio-contract): skip zero-weight vault mandate checks (#12889)

Refs AGO-1176

## Description

Skip zero-weight instruments before consulting TVL observations.

### Security / Scaling / Documentation / Testing / Upgrade Considerations

N/A

feat(portfolio-contract): enforce global delegated mandates (#12848)

## Description

A portfolio owner can grant an off-chain agent allocation authority without granting unlimited discretion. This PR enforces the optional global limits defined in #12847: one `maxWeightBps`, `minVaultTvlUsd`, and `maxVaultShareBps` set applies uniformly across all applicable instruments in the delegation.

Every delegated quantitative check occurs after the contract allocates, starts, and publishes an agent-attributed flow. `maxWeightBps` then checks every non-cash position immediately. Limits that need market evidence are checked when the planner resolves the plan, using the attached portfolio balance snapshot and each instrument's TVL observation.

The proposed target remains scoped to the running flow until every applicable constraint succeeds. Only then does it become portfolio policy and only then can movement steps execute. A violation instead terminates the attributed flow as failed, retains its agent, policy version, proposed allocation, stable `mandate.*` constraint identifier, and affected instrument for Activity, and leaves the prior policy and assets unchanged.

Cash remains exempt, missing required observations fail closed, and owner operations remain unconstrained. The change also implements owner-signed `ChangePermissions` and `Revoke`, preserves policy-version checks, and keeps the planner's reserved delegation unreachable from those owner operations.

The empty-plan early return is also moved ahead of EVM deposit setup, avoiding unnecessary Permit2 spender provisioning for a no-op plan.

Answers [AGO-1067](https://linear.app/agoric/issue/AGO-1067). PR 2 of 4, stacked on #12847, followed by #12849 and #12850.

### Security Considerations

Maximum weight is derived from contract state. TVL and portfolio-value checks use planner-supplied observations, so they catch inconsistent plans and ordinary policy errors but do not contain a compromised planner. Missing data rejects instead of bypassing a limit. Rejected proposals cannot replace portfolio policy or begin asset movement. `ChangePermissions` and `Revoke` require the existing owner-signed path and each advances `policyVersion` once.

### Documentation Considerations

Mandate failures use stable prefixes: `mandate.maxWeight`, `mandate.minVaultTvl`, `mandate.maxVaultShare`, and `mandate.observations.missing`. Every quantitative rejection is published as a terminal agent-attributed flow.

### Testing Considerations

Coverage exercises one global limit across multiple instruments, cash exemptions, missing observations, stable failure identifiers, stale policy versions, lifecycle authorization, and boundary inequalities. The maximum-weight regression also verifies that rejection creates a failed flow without changing policy or installing movement steps. Dishonest-planner containment is outside this design.

### Upgrade Considerations

Deploy this contract with or before #12849. Until the planner attaches observations, a delegated flow carrying a TVL or vault-share limit fails closed. `maxWeightBps` is enforceable immediately.

Remove Array.from({ length }) (#12860)

Closes: https://linear.app/agoric/issue/AGO-1095/workaround-arrayfromlength-broken-in-xsnap
Supersedes: #12838

Refs: #12829

## Description
#12829's increased validation introduced an on-chain regression with handling of arrays in EIP-712 because of a bug in `Array.from` in our XS version.

This PR fixes that, and removes all other uses of `Array.from({` in the ymax contract, with a test verifying that string does not exist in the bundle. A proper fix at the xsnap lockdown level is filed as a follow-up: https://linear.app/agoric/issue/AGO-1091/repair-arrayfrom-in-the-xsnap-lockdown-bundle-so-contract-code-can

The PR also fixes a testing regression I believe was introduced by #12551 or potentially earlier, where swingset tests meant to run with an xsnap worker in fact ran with a local worker. There are likely remaining cases where this is not working quite right, but they're left to a follow up: https://linear.app/agoric/issue/AGO-1090/snapshot-caching-runutils-snapshotsts-isnt-a-transparent-cache

Running swingset test under xs uncovered another test limitation: some test assertions came to rely on the debug nature of local lockdown, with automatically quoted error details. This PR takes the approach that swingset tests running under XS should similarly be using a debug version of lockdown, and adds a `globalThis` based plumbing for it.

### Security Considerations
The xsnap lockdown debug avoids using an env variable since a chain should never end up using a debug version of lockdown regardless of env variables.

### Scaling Considerations
This change may introduce a regression in testing time, since we now go (back) to running some swingset tests under xsnap instead of a local worker.

### Documentation Considerations
None

### Testing Considerations
See above

Fixed a few test issues found along the way (now stacked first)

### Upgrade Considerations
The changes here mostly affect tests or the contracts using orchestration like ymax, which would need to get upgraded. Since we haven't deployed the changes from #12829 yet, the next release can pick it up without on-chain regression.

feat: add claimRewards for aave (#12711)

closes: [AGO-556](https://linear.app/agoric/issue/AGO-556/ymax-contract-should-be-able-to-claim-reward-tokens-on-aave)

## Description

Adds implementation of `claimRewards` for aave protocol<br>A step like this can be used to claim these rewards:

```
 {
          dest: '@Arbitrum',
          src: 'Aave_Arbitrum',
          amount: emptyAmount,
          fee: feeCall,
          claimRewards: {
            minAmounts: [1234n],
            tokens: ['0x132123'],
          },
 },
```

### Testing Considerations

unit tests have been added, but e2e testing has not been performed, since that can only be done in a mainnet environment

### Upgrade Considerations

redepolyment of ymax contract is required for this feature

chore: add huma usdc main vault (#12822)

closes: https://linear.app/agoric/issue/AGO-936/add-huma-usdc-main-vault

## Description
Add the address for Huma USDC Main to the ymax contract 

### Testing Considerations
Can only be tested once deployed to ymax0 mainnet

### Upgrade Considerations
Both ymax0 mainnet and later ymax1 mainnet contract must be redeployed for this address to be registered on them

fix(cosmic-swingset): tolerate non-JSON object uppgrade info

fix(cosmic-swingset): tolerate non-JSON object uppgrade info

chore: add rockawayx usdc yield vault (#12821)

closes: https://linear.app/agoric/issue/AGO-927/agoric-sdk-register-rockawayx-usdc-yield-vault-erc4626-morpho-v2
## Description
Adds the address for the RockawayX Usdc Yield vault to the ymax contract

### Testing Considerations
Can only be tested once deployed to ymax0 mainnet

### Upgrade Considerations
Both ymax0 mainnet and later ymax1 mainnet contract must be redeployed for this address to be registered on them

Agoric Upgrade 23 release

feat(portfolio-contract): Open with grant (#12805)

closes: AGO-615
refs: kriscendobot/garden#42

## Description

This PR adds `OpenPortfolioWithGrant`, a permit2-wrapped EVM operation that opens a portfolio and grants allocation control in one signed message.

- this adds a new wire operation to the EIP-712 surface, with grant fields nested under `grantee` for human legibility
- the combined flow preflights the grantee smart-wallet deposit facet before allocating a portfolio, then opens the portfolio and delivers the delegation before starting funding
- this is fail-closed for delegation delivery before funding starts, but not fully atomic overall: a later funding failure can still leave a delegated-but-unfunded portfolio

This does not include EMS/UI work to construct or submit the new message outside the existing test tooling.

### Security Considerations

- In the combined flow, a grantee lookup failure rejects before the portfolio kit is allocated and before funding starts, so no orphaned shell portfolio is published and no deposit is pulled for an unknown grantee.
- Funding is still fire-and-forget after the grant succeeds, so a later funding failure can leave a delegated-but-unfunded portfolio.

### Scaling Considerations

N/A.

### Documentation Considerations

N/A.

### Testing Considerations

`multichain-testing/scripts/ymax-tool.ts` is not updated to support this.

### Upgrade Considerations

Suggested rollout:

- publish the `portfolio-api` package with the new EIP-712 message type
- deploy the updated `portfolio-contract` when ready; it does not need to be deployed at the same moment as the `portfolio-api` publication
- upgrade EMS after it consumes the newer `portfolio-api`; at runtime EMS can still present a backwards-compatible `OpenPortfolio` operation to YDS until the new flow is enabled
- update YDS typing after it consumes the newer `portfolio-api`; it should explicitly `Exclude` `OpenPortfolioWithGrant` from operation types that it expects to handle directly
- upgrade UI after the EMS relay path supports the message, and gate the new `OpenPortfolioWithGrant` flow behind a UI flag before enabling it end-to-end

No contract state migration is required.