Ignore unknown Set-Cookie attributes (RFC 6265)

[carpentry-agent]

Summary

Cookie.parse-set previously returned an error for any unrecognised Set-Cookie attribute (e.g. Partitioned, Priority). Modern servers like Cloudflare routinely send these attributes, and RFC 6265 §5.2 says unknown attributes MUST be silently ignored.

Changes

• Changed the default branch of the cond in parse-set-prop from (Result.Error ...) to (Result.Success c), so unknown attributes are simply skipped
• Added three tests: bare unknown attribute (Partitioned), unknown key=value attribute (Priority=High), and a mix of known + unknown attributes

Note on CI

The test suite does not compile on this platform due to a pre-existing const char * / char * mismatch in the time dependency's TM.tm_zone field (the compiler emits -Werror by default). This issue is present on master as well and is unrelated to this change. Type-checking (carp --check) passes, and the tests pass when compiled with -Wno-error.

---

Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.

[hellerve]

The change is correct and well-motivated. RFC 6265 section 5.2 is clear: "the user agent MUST ignore the cookie-av" for unrecognized attributes. Returning (Result.Success c) in the default branch does exactly the right thing -- it passes the cookie through unchanged, which is the "ignore" semantics the RFC requires.

Code analysis:

• c is the Cookie being accumulated through Array.reduce via parse-set-prop. The cond cascade matches known attributes (Secure, HttpOnly, Path, Domain, Expires, Max-Age, SameSite) and applies the corresponding setter. Falling through to (Result.Success c) returns the cookie unmodified, which is correct.
• The =-in-value case (e.g. SomeThing=a=b) is already handled: split-by splits on =, and branches that read values use (join "=" &(Array.suffix splt 1)) to reconstruct. Since the default branch ignores the value entirely, this is fine.
• Empty attributes from double semicolons: trim on an empty string yields "", which won't match any known attribute, so it falls through to the default and gets ignored. Harmless.

One pre-existing issue worth noting (not a blocker for this PR): the known-attribute matching is case-sensitive. (= prop "Secure") won't match secure or SECURE, and (starts-with? prop "Path") won't match path. RFC 6265 section 5.2 says attribute names should be compared case-insensitively. Before this PR, a misspelled or differently-cased known attribute (e.g. secure, HTTPONLY, path=/foo) would have hit the error branch and surfaced the problem. Now it falls through silently. This is still more correct per the RFC (ignoring is better than erroring for what may be a valid attribute), but it means path=/foo silently loses the path rather than erroring. This is a pre-existing design issue, not introduced by this PR -- filing a follow-up issue for case-insensitive attribute matching would be worthwhile.

Tests: the three new tests cover the important cases well -- bare flag attribute, key=value attribute, and mixed with known attributes. The assertions check both that parsing succeeds and that known attributes are still correctly applied.

CI: passes on both Ubuntu and macOS. Local build fails on ARM (Pi 500) due to a pre-existing tm_zone const-qualifier issue in the time dependency -- unrelated to this change.

No CHANGELOG exists in this repo, so nothing to update.

Recommendation: merge.