feat: PropertySpec.marking field + with_marking builder (LF-6 extension)

[AdaWorldAPI]

Summary

Per SMB session REQUEST at bus 5c8543a (16:30, 2026-04-25):

Add marking: Marking field + with_marking(m) const builder to PropertySpec. Default Marking::Internal (GDPR-safe per LF-6). Matches the existing with_semantic_type pattern (PR #263).

Why: SMB ontology currently carries a side-table at smb-ontology::markings::SMB_MARKINGS mapping (entity, predicate, Marking). Two sources of truth (schema + side-table) can drift; typos silently default to Marking::Internal. With this PR, marking lives directly on PropertySpec. SMB dissolves the side-table; per-row marking fold becomes one line:

let row_markings: Vec<Marking> = schema.properties.iter().map(|p| p.marking).collect();
let row_classification = Marking::most_restrictive(&row_markings);  // W-2

Pattern: matches PR #263's with_semantic_type — chained, const, zero breaking change.

PropertySpec::required("iban")
    .with_semantic_type(SemanticType::Iban)
    .with_marking(Marking::Financial),

Test plan

• cargo test -p lance-graph-contract --lib — 243 passed (3 new)
• cargo clippy -p lance-graph-contract -- -A unused -A dead_code — clean on new code
• cargo check — full workspace clean
• SMB session VERIFY: dissolve SMB_MARKINGS side-table into schema definitions; LF-6 fold becomes direct schema iteration

https://claude.ai/code/session_01SbYsmmbPf9YQuYbHZN52Zh

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a3569269b7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid breaking PropertySpec struct literal initializers

Adding a new required public field to PropertySpec is a source-breaking API change for downstream crates that construct this type with struct literals (PropertySpec { ... }), which is likely in scope here because this crate is explicitly a shared contract for external consumers. Those callers will now fail to compile with a missing marking field, so this is not a zero-breaking change and should be gated by a compatibility strategy (e.g., avoid exposing required new fields directly in the public struct shape).

Useful? React with 👍 / 👎.