Add CIP-179 v5 linked survey linking and voting

[Cerkoryn]

Summary

Supersedes #4152 with an implementation based on the stabilized CIP-179 v5 specification and the published cip-179 package from @mpizenberg's Tessara.

This PR focuses on linking, rendering, and submitting survey responses. Tally calculation and results display from the previous proposal are left out of scope for simplicity.

List of changes

• Add an immutable backend endpoint that returns exact metadata-label-17 CBOR by transaction hash and survey index
• Add a feature-flagged transaction-hash field when creating a governance action
• Validate linked definitions, survey indices, governance-action expiry, and UI renderability before authoring
• Add the CIP-179 link to CIP-108 JSON-LD without changing metadata hashes for actions that do not use surveys
• Render public and sealed surveys within the governance-action voting form
• Support single-choice, multi-select, ranking, numeric-range, points-allocation, rating, and registered custom methods
• Verify and optionally apply hash-anchored external presentation content
• Encode response metadata with the existing Cardano serialization library and attach it to the governance vote transaction
• Seal eligible responses using the published tlock integration
• Add limits and defensive handling for malformed, oversized, unavailable, or unsupported surveys
• Keep the feature disabled by default through VITE_IS_CIP179_ENABLED

Verification

• Frontend TypeScript and lint pass
• Production frontend build passes
• 216 frontend tests pass, including native metadatum CBOR, link authoring, envelope validation, and rendering limits
• Desktop and mobile Storybook scenarios were visually inspected with no page errors, MUI warnings, or overflow
• Haskell changes were statically reviewed but not compiled locally because the Haskell toolchain is unavailable

Checklist

• My changes generate no new warnings
• My code follows the project style guidelines
• I have commented code where additional context is useful
• I have made corresponding changelog changes
• I have added tests that prove the feature works

I was unfortunately unable to build all of the necessary dependencies to validate all of the changes. But I was able to build the storyboard and visually inspect some example surveys that were attached to governance actions. If this PR passes validation and we can get it merged into https://govtool-preview.cardanoapi.io/ at least, then I would be happy to do some conformance testing of my own with real surveys that are live on Preview and compare them against other tools' CIP-179 implementations.

This PR was constructed with heavy assistance from GPT-5.6 Sol High and I did my best to validate what I could locally. My apologies for not being able to test the entire end-to-end flow however 🙏

[Cerkoryn]

Tagging @spannercode @mesudip and @bosko-m for review if possible 🙏

[kusssal]

83a9678
Above commit is deployed at https://pr-4184.dev.gov.tools/.
with pr specific docker images built at https://github.com/IntersectMBO/govtool/actions/runs/32009346968

[Cerkoryn]

@kusssal apologies for the delay. I just pushed an update to fix a CBOR decoding issue in part of the code I introduced (also in IntersectMBO/govtool-voting-pillar#28). I was looking into the example you deployed at https://pr-4184.dev.gov.tools/ for testing, but it appears the feature flag isn't enabled.

Is it possible you can update to the latest commit in this PR and then re-deploy with the feature flag injected through the container entrypoint and enabled? If so, I would be happy to test it with live CIP-179 surveys on Preview myself.

[Cerkoryn]

Apologies, but could you pull the latest commit and then redeploy the updated frontend and backend with VITE_IS_CIP179_ENABLED=true one more time?

I was testing the latest deployment and discovered several isseus: Malformed survey presentation data that could break rendering, oversized/stalled downloads, missing expiry and index validation, and clearing optional answers incorrectly blocking submission.

All of these are fixed in the latest commit and I am now creating a CIP-179 survey linked to a governance action on Preview for further testing.

[kusssal]

Hey @Cerkoryn ,the latest commit is now deployed, with VITE_IS_CIP179_ENABLED=true

[Cerkoryn]

@kusssal thank you for your patience 🙏

I successfully tested the deployed CIP-179 public survey-response flow on Preview: transaction.

The survey answers were correctly encoded, with valid constraints, survey linkage, credential proof, and signatures. The governance vote and rationale anchor were also preserved correctly.

I did push a small numeric-input fix that is mostly a cosmetic change in the UI. Previously, the fields visually accepted text even though invalid answers already blocked submission. They now reject nonnumeric input and display clear bounds/step errors while retaining GovTool’s styling.

From this testing, I would feel comfortable merging if you are. Alternatively, we can re-deploy one more time if you’d prefer to validate the numeric-input fix first.

[kusssal]

Thanks! @Cerkoryn ,The latest commit has been deployed and and I also successfully completed the CIP-179 flow on Preview: transaction. Before merging, could you document the relevant scenarios using our user-story testing format and add corresponding Playwright tests? With that coverage in place, we’ll feel comfortable merging the PR.

[Cerkoryn]

@kusssal how is that looking for you?

[kusssal]

@Cerkoryn Thanks for adding the user stories and Playwright coverage.Looks good , ready to merge

[kusssal]

@Cerkoryn Thanks again for the contribution. As we are migrating the backend from Haskell to TypeScript, I’d really value your feedback: how did you find making the backend changes in Haskell for this feature? Were there any parts that felt particularly difficult, slow, or hard to validate that we should improve as part of the TypeScript migration?

[Cerkoryn]

@kusssal actually the Haskell changes were quite difficult for me and I could not have done them without the help of AI and significant trial-and-error testing 😅

I don't have much experience with Haskell or functional programming, but Typescript is much more familiar and something that I have worked a lot with. I think simplifying the development stack into Typescript as much as possible would be a huge step in the right direction.