feat(view): allow finalize bodies to call view functions

[mohammadfawaz]

Closes #3252. Builds on #3257 (query → view rename) and #3238 (the read-only feature).

A function's finalize body can now call a view function — same-program or imported. Views remain leaves (cannot call other views).

finalize compute_total:
    input r0 as address.public;
    call my_token.aleo/get_balance r0 into r1;  // call a view
    add r1 100u64 into r2;
    set r2 into total[r0];

Views may also declare zero outputs and serve as cross-program preconditions (Aleo analogue of Solidity's function require_member(address) external view { require(...); }):

view require_member:
    input r0 as address.public;
    get.or_use members[r0] false into r1;
    assert.eq r1 true;

finalize transfer:
    input r0 as address.public;
    call vw_acl.aleo/require_member r0;   // no `into`; aborts the tx if the guard fails
    ...

What's enforced

• Construction: Finalize::add_command permits Call; call.dynamic rejected via new Command::is_dynamic_call. Constructors still forbid call entirely. View inputs / commands / outputs are all many0 (matches function); the body constraints — no record-touching ops, no state writes, no async/await/call/rand.chacha — are enforced by ViewCore::add_command, not by arity.
• Type-check: Opcode::Call(_) allowed only if the target resolves to a view (functions / closures → bail); Call::output_types_for_view additionally checks each operand's type against the view's declared input type (cross-program structs resolved via qualify) and verifies that the destination count matches the view's output count (so call vw/guard r0 into r1 against a zero-output view is rejected at deploy); CallDynamic is explicitly bailed in the finalize type-checker (was previously only blocked upstream by Finalize::add_command).
• Runtime: finalize_command_except_await special-cases Call → evaluate_call_to_view (loads inputs from caller registers, runs view body against live store with caller's FinalizeGlobalState, writes outputs to caller destinations). Zero-output views run their body to completion, write nothing back; an assertion failure inside the body propagates as a finalize rejection.
• Cost rollup: cost_per_command folds the callee's view_cost_for_single_view into the caller's finalize cost, so TRANSACTION_SPEND_LIMIT bounds the combined cost.
• V15 gating: Program::contains_v15_syntax flags any call in a finalize body (pre-V15 finalize forbade call). The arity relaxations ride inside the same V15 gate.

Notes

• View types cached on Stack (mirror of existing finalize_types) so evaluate_call_to_view has cheap structural access.
• The synthesizer/process/src/view.rs module is now unconditionally compiled; only the external evaluate_view_at_height API + HistoricFinalizeStore stay gated on --features history.
• In-block calls avoid the Stack-snapshot caveat from docs/test(query): qualify Stack snapshot claim + add name-collision tests #3250 — the caller's finalize is already mid-atomic-batch.
• The post-view-body finalize_operations.is_empty() invariant is now ensure! (release-time) instead of debug_assert!, so a regression that lets a write through the view type-check fails closed.

Tests (test_v15/views.rs + view/parse.rs)

Same-program and cross-program lifecycle (incl. repeated cross-program calls), non-view target rejected at deploy, arity / destination-count / input-type / destination-type mismatches rejected at deploy, runtime view failure inside a finalize call rejects the tx with batch rollback, multiple-call + interleaved write read-write-read, multi-output + struct return, single-call-only finalize body, zero-input view from finalize, view-call inside branch.eq (skip + not-skip paths), V15 bidirectional gate, call.dynamic rejected at parse, view body with call rejected at parse, zero-output guard view (assertion pass: caller's finalize proceeds; assertion fail: tx finalize-rejected, no state change), call vw/guard r0 into r1 against zero-output view rejected at deploy, zero-command passthrough view parses, fully-empty view parses.

[vicsn]

Could it be worth creating a new FinalizeCall operation, giving us extra clarity and assurance that old edge case Call behaviour doesn't leak into the finalize-version of doing calls? Or would it just be a bunch of code duplication for little benefit?

[mohammadfawaz]

Addressed in 0593427 — moved the view-target handling into a dedicated Call::output_types_for_view so the transition-side Call::output_types never sees views. Creating a separate FinalizeCall doesn't feel worth it 🤔